|
Re: A Brief Look at C++0x
|
Posted: Jan 11, 2006 8:49 AM
|
|
Regarding the discussion about GC and developer productivity. I'm a little wary of the request for, or promotion of, GC, as it may contribute to an ignorant attitude to, or bad habit of, resource ownership management. Given that GC doesn't automate this fully, in particular not lifetime management, at all, this may lead you into more troubled water, later in the life of the project.
To use an analogy: Would it be better use of your resources, if you, in a house:
a) Fetch things from where they are stored, and put them back again when you're done with them.
b) Fetch things from where they are stored, and just drop them on the floor when you're done with them, and hire a maid to regularly clean up after you...
I remember learning Java, coming, as I did, from C++, where you're used to "clean up after yourself", and starting to just "drop things on the floor"... It just felt unnatural: "But I know I'll not need this object, anymore, can't you just delete it right away?".
This may lead into an "illusion" that you don't need to care about memory ownership issues, until you meet the wall, one day, where you run out of memory, or the GC trashes, and you learn that you may have to set long-lived references to null, or the objects they refer to won't be collected, and that if you create lots of objects, in particular big ones, that are needed for a short time (like the Image objects in my project), you may run into such problems.
So... You may come to, at least for some applications, that the memory management issues could be _easier_ with RAII and smart pointers, because you only heap-allocate what you need to heap-allocate, and you get very specific, deterministic lifetime of it (and you might use memory pools, etc.), than with an unpredictable GC.
For example, if you need to explicitly null references, for them to be collected, what have you gained? You may run into _harder_ problems, trying to figure out what references are kept where (there may be large structures "kept alive" with a reference that in reality is no more used, but can't be collected because of it).
Someone (I think it may have been Robert C. Martin in "Agile Software Development") made the analogy of keeping your code in shape, to working in a tidy kitchen: Everyone knows it goes fastest to prepare food in a tidy and clean kitchen. You may save a little time, by not cleaning up after you, but the accumulating cruft will mean that it takes longer and longer to make food (finding things, and clean them, as you need them), and ultimately you'll use much more time in this way, in total, than if you kept the kitchen tidy and clean, throughout.
It feels a little similar with GC: Sure, you can just "drop things on the floor", but it may make you slower in the long run.
|
|