Re: If GC is the solution, then what is the problem?
Le Chaud Lapin wrote:
Ah true...but let's not kid ourselves. If you pin a pro-GC person to
the wall and ask him why he wants GC, I suspect that it would not be
for the rare, esoteric designs that really do beg for GC, but for the
everyday, "i'll just new() this and be done with it" code.
Before you start saying that the tool should not be banned for lack of
skill in the craftsman (which I entirely agree with) I think it is
instructive to ask...:)
"What percentage of real-world designs have an inherent need for GC?"
I am not pro GC as such but it would be most useful for collections,
provided it would mean you could have vector<T*> instead of
vector<shared_ptr<T>>.
The advantage of the former is that if you grow the vector such that
you need to reallocate, because T* is a POD it can use a memmove()
which should be a lot faster than copying all the shared_ptrs
individually. That is, of course, assuming that a gc-pointer is still a
POD.
That in addition, of course, to all the copies that are made every time
the vector is accessed.
Assuming that you want C++ to remain a high-performance language that
could be significant.
It would be good to have the option though. You could call new(gc) T to
obtain a garbage collected pointer, new T would not. So in your vector
you would need to call new(gc).
This is the crux of what the non-GC people are saying (or at least I
am). We regard GC a crutch that encourages bad design. We believe
that the ratio of designs where it really does belong is so small that
in those cases, it would be better to implement GC as part of the
resolution of the design and not change the language itself.
That is like saying that using shared_ptr (and any other smart-pointer)
encourages bad design because the user does not have to worry about
deleting it as long as there are no circular references.
In fact you can say that about any library. STL and boost libraries
encourage people to use the libraries to write robust C++ without
knowing all the deep inner-workings and all the tricks involved with
the language in its raw state.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]