== Quote from Daniel de Kok ([EMAIL PROTECTED])'s article > On Fri, 14 Nov 2008 22:48:41 -0600, Tony wrote: > > breakers for some (a lot?) of software. That's why I think GC should be > > an opt-in rather than an opt-out choice. That's a key characteristic of > > C++: opt-in. And I really, really like that level of creative freedom. > That's not necessarily good. There are now multiple commonly-used methods > for pointing to instances in C++: plain pointers, references, and smart > pointers, all with different usage and semantics. It's a burden for > library writers and library users. An opt-in GC only makes the burden > heavier. > In contrast, most GC-ed languages make life simpler not requiring a > plethora of alternate management/lifetime schemes. > Take care, > Daniel
Agreed. Also, whether or not GC is the default in a language deeply affects the de facto standard way of doing things. For example, in C++, you don't have nice slice syntax in STL because STL is designed for use with manual memory management. Also, from what I've seen and heard, you tend to lose a lot of the theoretical efficiency of manual memory management when you replace it with ref counting (read: poor man's GC), or lots of copying to make every object have a clear owner. I translated a small but computationally intensive machine learning program from C++ to D a few months ago, and the D version was drastically faster because it avoided lots of excess copying. Granted, the C++ version *could* have been more optimized, but in the real world, people don't have forever to optimize all this stuff away. Another interesting thing about D that I don't think people give enough notice to is how cleanly you can mix manual and automatic memory management to get the best of both. GC is fast (compared to manual memory management) when you have large amounts of small objects with non-trivial lifetimes. It is slow when you have a few large objects with trivial lifetimes. The way I usually write my code, which is generally number crunching type stuff that can require lots of scratch space, is to use GC for all the small objects and objects where the lifetime is non-trivial, and free things like scratch arrays that can be large and are only used within one function manually.
