Re: Visual C++ Book
"MrAsm" <mrasm@usa.com> wrote in message
news:ccvu03tefvaukbrqdvbtcjmaanjt3r842m@4ax.com...
no, I'm sure I don't have the same experience and knowledge of C# that
you have. I'm just learning C# writing simple test apps (I like
learning in small pieces), so I didn't write anything non-trivial in
C#. I'm still in learning mode, and in fact I'm trying the VC#2005
Express (a great gift by Microsoft to C# learners!).
Oh, OK. C++/CLI was the first way I found to create a working .NET app I
use every day, so that's why I like it so much.
I respect your opinion that you like differentiating between instance
data member (.), pointed instance data member (->), and namespaces
(::). To all of us C++ programmers, it seems very clear because we are
used to that for years. But I think that the "spirit" of C# is very
different from the spirit of C++, I think that the spirit of C# is
about *simplification*, like Java.
Of course, there are also some negative points about that.
For example, I like the deterministic finalization of C++, i.e. that a
destructor is automatically called when a function/method/block is
terminated ("}").
So, if I access a resource e.g. a file with a File class with a
destructor that closes the file, I know that the file is closed (the
resource is released) when the block ends.
On the other side, it seems to me that I have to force the resource
release in C# (something like explicitly calling a method like
File.Close). I read about this IDisposable interface, but I did not go
very deep with it.
However, I believe that, when memory constraints or resource
management do matter, when top performance is a must, etc. - as I
wrote in another post - C++ is the way to go. But, in these cases, I
would also not consider the managed world of .NET, but simply go
*native* with C++ and MFC.
If Xaml is successful, we will soon see many .NET front-ends, perhaps
written in Orcas and Orcas+1.
-- David