WARNING: This digresses into a rant by the end... You've been warned. If you like to have your garbage collected for you then use one of the management strategies present in C++. If you like delayed freeing, overload new or use a library that does this. Really, the difference between C++ and most other programming languages (that are strongly typed) is that C++ doesn't make any assumptions about what you are going to do with it because of its most basic principle: you don't pay for what you don't use. If you want garbage collection, you can have it: it's not like C++ prevents this. By the same token, Java and C# don't allow you to make any decision here which might be best in certain circumstances, but it certianly isn't always ideal. If you want the subset of features that say java has, you are welcome to create these restrictions in C++ all while remaining more portable.
I personally use garbage collection every once in a while in my C++ code. It is not usually the right tool for me, but there are circumstances where it makes sense. I generally use it when I have data that isn't really owned by any object. It is data that many parts of the program reference and some wish to keep a copy for themselves. This is how the std::string class is implemented in C++. Reference counting and copy on write. But I'll be damned if Java takes over the world because there are programmers that don't know when they need to use garbage collection. If you can't avoid memory leaks, fine, don't use C++ or C, but don't blame the language. You could use garbage collection if you need it; don't make us all stoop to your level of competency and don't try and claim that your language is just as fast when it isn't. - Nick On Nov 12, 2007 11:55 PM, Hellwig Geisse <[EMAIL PROTECTED]> wrote: > On Mon, 2007-11-12 at 20:17 -0800, steve uurtamo wrote: > > C > > garbage collection: free(). > > Well, that's not garbage collection. You will begin to notice > that if you are using shared data structures with different > lifetimes. The question that comes up again and again is "can > I free this structure here or does any part of my program hold > a private pointer to this piece of data?" It is sometimes > possible to group freeing objects (e.g., a compiler can free > data structures it needs to compile a function when the end > of the function is reached - this is called "arena freeing") > but not always. > > > very fast. > > And it's not fast either. Free() has a reputation of being > slow, and that's not surprising if you look at the way it is > almost always implemented: scanning a list of addresses in > order to amalgamate the newly freed memory with adjacent free > areas. > > My personal experience is: if you can tolerate the 5-10% loss > in execution speed, a real garbage collector is invaluable. > > Hellwig > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
