Re: Garbage Collection - The Trash Begins To Pile Up
Andreas Huber wrote:
Did they really claim "not difficult"? Where did you get that from? I've
only ever heard that things become easier.
Microsoft Writes:
"Last month, I described the motivation for garbage-collected
environments: to simplify memory management for the developer."
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2
'.NET 2.0 For Delphi Developers' writes:
"At the same time, .NET offers garbage collection that frees us from
memory management overhead."
http://www.midnightbeach.com/.net/
'Sams Teach Yourself Visual C++. .NET in 24 Hours' writes:
Using Managed Code for Easy Memory Management
http://safari5.bvdep.com/0672323230/ch05lev1sec2"
While looking for references, I found this statement about Java. Why
am I not suprised:
"Although Garbage Collection (GC) in Java attempts to simplify memory
management by relieving the developer from allocating, tracking and
freeing memory, it still cannot totally eliminate memory leaks. Objects
may be inadvertently kept beyond their useful lives, or may be
referenced so that GC will not scoop them up. Detecting memory leaks,
and finding and eliminating their root causes, are crucial steps in
improving the performance of a Java application."
http://websphere.sys-con.com/read/258406.htm
Any engineer who designs a program that contains these problems in
such significant quantities as to warrant an article being written
about it should be ashamed of him/herself.
I fail to see how the above is relevant. A similar article could be
written about any language that offers manual dynamic memory management
(memory leaks, dangling pointers, etc.). As always, a fool with a tool
is still a fool. Ah, and don't get me started about memory fragmentation
problems in C++, but that's really beside the point.
But in this case the fools are trying to deposit their fools' gold in
our bank because their bank went bankrupt.
C++ is what it is. We stated that, if you are an engineer who knows
how to build systems (in any engineering disciplines), and you are in
tune with the mechanics of RAII constructor/destructor call sequence,
then you should not have many problems with memory management. We did
not claim more. We never said you could call new/delete willy-nilly
and magic would happen. What you see is what you get.
The GC people are saying that, if you use GC, it relieves you from
having to think about memory management. This is a lie. That
Microsoft is writing so many articles about how to "properly" do memory
management under .NET is plain evidence of this fact.
The problem is that, though this lie is beginning to reveal itself in
other languages, that doesn't seem to stop people from trying to
reinvent it in the context of C++.
The truth is that memory management is complex for any beginner. The
only real hope for "proper" memory management is to engineer the
system appropriately.
I clarify my original question: Let's say you have a software written
twice, once in C++ and once in a GCed language (C#, Java). One and the
same engineer writes both systems who is proficient in memory management
in C++ (RAII, smart pointers, etc) and GCed languages. I believe the
engineer will typically spend considerably less time thinking about
memory management when building the system in the GCed language and
that's all that counts in terms of usability.
I disagree. I have no experience in C# and not much in Java, but I
have used Lisp/Scheme much, and of course, C++. I don't think about
memory management too much in C++, so C# would automatically lose. I
spend most of my time thinking about
1. data structures and algorithms
2. clean interfaces so that users of my class will feel good when they
use them
Memory management is not on this list. I have used the
constructor/destructor model so many times, when I go to write
Foo::~Foo(), I am almost disappointed, as there is not much to think
about: get write of whatever memory was allocated in the constructor.
As far as usability goes, as I stated earlier, I get more questions
from programmers who switch to C#/.NET asking me to help them fix their
memory management issues (over the Internet) than I ever got for C++.
I also used to receive C++ questions also, but I can honestly say that
the C# code is typically so sprawling and unwieldy that the best I can
tell them is to get a box with more RAM.
I also think you should read the articles that are being written by
Microsoft and ask yourself, honestly, what is the real difference
between intellectual capacities to understand
1. C++ constructor(new)/destructor(delete)
versus
2. C# special cases of finalize, dispose,
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]