Re: If GC is the solution, then what is the problem?
marius lazer wrote:
Victor Bazarov wrote:
marius lazer wrote:
Than what am I getting by using GC? Nothing squared!!! :-)
Not sure what your smiley is all about (perhaps indicating
that you're not serious), but GC (actual free store
management) in a separate thread is a great improvement
compared to "inline" free store management that now takes
place in the same thread as destruction and deallocation,
wasting valuable time that could otherwise be spent
calculating or communitating.
I'm dead serious and I'm sorry for the smiley (I just wanted
to soften the statement). My appologies to all.
OK then, we won't only overload C++ keywords, but now we have
multi-threading as part of this all. How many of today's
complex C++ applications are thread-safe (forget about
designed for intra-process concurrency which are even fewer)?
Probably a lot less than are garbage collection safe:-).
I'm not talking about "legacy", but nowadays production apps.
Agreed. Including a large number that were designed for a
multithreaded environment.
Based on what I've seen there are few (should be all, but
reality and investment in re-engineering is against me). That
being said, I'd love to see threading being in the C++ spec
waaaay before GC (afterall, GC relies on it, right?). I don't
think there is anyone sane on the plannet not recognizing that
C++ will have to really-soon address intra-process concurrency
at the language level (but, again, I might be wrong...).
I think you're right there. I think that there is a very strong
consensus about this---including the fact that thread support is
even more important than garbage collection. (It's interesting
to note that the critical issues surrounding thread safety is
the memory model, and that the people who are most actively
working for garbage collection are the memory model experts.
Which means that while there is more or less a consensus for
garbage collection in the committee, it's not advancing very
fast, because the experts in it are too busy with threading.)
Now back to GC. Yes, the theory sounds really good, but once
the standard enforces GC we'll take another 6-10 years to get
it mainstream (don't forget that most compilers still don't
make it through boost or Loki).
I only know of one major compiler today which doesn't support
Boost. (Regretfully, it's the one I have to use most:-(.) And
they're committeed to supporting Boost in the next major
release.
You do have a point, however. If standard garbage collection
(or threading, for that matter) is treated about like export,
there's nothing to be gained by standardization. In general,
the treatment of export makes me wonder about the value of
standardization in general.
Still, unlike export, there is a generally available
implementation which the vendors can use, at least for the brunt
of it. And unlike export, Microsoft seems to be behind it,
which will put commercial pressure on the other vendors to
support it. (Supposing, of course, that the Microsoft
implementation is in some way related to what the standard
decides, and not specific to C++/CLI or managed C++ or whatever
it is called this week.)
After going through this long thread (starting with an open
mind) I just don't feel I'd be getting enough out of standard
GC in C++ to justify the "burden" on most for the "need" of
some
Given that the "some" with the need represent about 90% of the
C++ applications, and that the "burden" when you don't need or
want it is 0, I can't quite agree.
(we arleady have all the tools available, just need to be
competent enough to use them well).
Several people keep saying that, but they don't seem to be able
to say what the tools are. We know that boost::shared_ptr isn't
sufficient, in itself.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]