for me personally i am way more productive with C# than i am with C++, and using the library is much more convenient/consistent than a mix/match of Win32, stdlib, or boost libraries.
back on topic, there is no X is better than Y. there is only X is better suited for Z than Y. in general i think learning C++ first will make you a better C# programmer....
the one thing you need to watch out for is not to think in the old language. learn to think in the new language.
people who have seen "VB6 style" code in .NET know what i'm talking about.... :'(
>> Plus, it helps improve performance -- if a large number of objects go out of scope at once, they don't need to all be destroyed immediately while your thread sits on its ass waiting.
The role that destructors play in memory management is just a side-effect of their real purpose; to do *something* precisely when the object goes out of scope. For example, you may have an object that writes an XML start tag in it's constructor, and a closing tag in it's destructor, eg:
Obviously, for things to work properly, the objects have to be destroyed in a specific order.Code:
xml_writer a( "outermost" ), b( "middle" ), c( "innermost" );
The importance and usefulness of the destructor really can't be overstated. Their absence from languages such as C# and Java is a real shame, indeed.
yes, you *could* do that with a constructor/destructor, but i'm still unconvinced from your XML example why C# lacking true deterministic deallocation is "inherently flawed."
edit: btw, i say true deterministic deallocation because even though in C# you can manually call Dispose() on an object, technically the instance is still available in memory, unlike C++'s delete.
>> but i'm still unconvinced from your XML example why C# lacking true deterministic deallocation is "inherently flawed."
That was just a very simple demonstrative example. There are literally innumerable mechanisms that can be described using the constructor/destructor idiom, as they essentially model a stack (and thus recursion), arguably one of the most important concepts of computer science. The question isn't "what are they good for?" but "what can't they be used for?".
well, if you're argument is simply to do something upon construction and destruction, rather than allocating/deallocating memory, then there really isn't much difference between C#'s IDisposable pattern vs C++'s destructor....
actually, in C++/CLI if you declare a C++ destructor it actually compiles into a Dispose() method, which via stack semantics Dispose() will automatically be called when the object goes out of scope.
i will say that *properly* implementing the IDisposable pattern in .NET is a complete pain in the butt with numerous places where you can screw up. and since it is a pattern, there is no guarantee that it will be done exactly the same across different libraries and programmers....which leads to more pain in the butt.
here's one of the most comprehensive guides to implementing the pattern:
Joe Duffy's Weblog
yes...25 pages printed.
>> i will say that *properly* implementing the IDisposable pattern in .NET is a complete pain in the butt
I don't even bother with it; I always invoke cleanup code manually. It sure would be nice if I didn't have to, though. ;)
Okay, this is confusing :(Quote:
Originally Posted by bling
Are you saying that although the programmer can call Dispose earlier (i.e., deterministic but manual deallocation), Dispose will be invoked automatically when the object goes out of scope? My impression (from Clemens Szyperski's annotation in the article you linked to) is that if the programmer does not call Dispose, Dispose will be called sometime during finalization, in which case it is not equivalent to the deterministic destruction provided by (standard) C++ destructors.
...and in a tangentially related point
...as opposed to stopping executing at ANOTHER point to do it, when you have no control on the performance hit.Quote:
Plus, it helps improve performance -- if a large number of objects go out of scope at once, they don't need to all be destroyed immediately while your thread sits on its ass waiting.
My point here is that this doesn't save time overall - the same work has to be done at some point, and if you're not in control of that then it will increase the memory footprint while those objects that are out of scope hang around.
It's a double edged cutting issue.
If a collection of 20,000 objects fall out of scope, how long does that take? It depends on what happens as they do. Tens of millions can be processed per second on typical hardware when the destructor is trivial, and depending on what's really going on, the net result (sometimes due to compiler optimization) can be zero work has to be done. That's almost never true on .NET; some under the hood management of the implied base object has to be managed at the minimum on a collection of such objects.
I always thought that it was deterministic, but apparently not. According to MSDN:
Note the misuse of the word "automatically".Quote:
The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur.
I see. It's deterministic iff the object is manipulated within the "using" syntax.
How is it misuse? It is true that the garbage collector automatically releases the memory for managed objects, since (at least ideally) the programmer does not need to manually do so.Quote:
Originally Posted by Sebastiani
I should have amended that in my edit. But yes, it is automatic (as long as the "using" syntax is employed, of course).
a) the programmer cannot deterministically clean up managed resources
b) IDisposable provides a pattern for cleaning up unmanaged resources (and optionally do so deterministically by calling Dispose() directly)
anyways, IDisposable is such a complicated mess probably because .NET has to support multiple languages. for most languages, Dispose() is optional, so if you do not call it, unmanaged resources will not be freed until the GC kicks in. however, for langauges like C++, which has RAII, Dispose() will automatically called when an object goes out of scope. i believe the C++/CLI compiler will automatically generate that code even if you didn't define it.