Re: If GC is the solution, then what is the problem?
Joe Seigh wrote:
Andrei Alexandrescu (See Website For Email) wrote:
a) Passing smart pointers around becomes too much of an efficiency
problem. With MT smart pointers the tipping point is particularly quick
to reach, but even ST smart pointers can significantly erode the code's
performance. This creates strong pressure to either use
pointers/references to smart pointers, or selectively use raw pointers
instead of smart pointers, both of which are a round trip back to the
problem we were solving with smart pointers. Besides, making the
decision on what cases ask for such bypassing of smart pointer semantics
has an ongoing development cost.
In multi-threaded programming, shared data has to be synchronized
properly and this will likely incur some amount of overhead no matter
what, whether the data is a pointer or some shared data the pointer
refers to.
Sorry, my point was different. I was referring to the cases in which
smart pointers perform _unneeded_ synchronization. Smart pointers lack
the horizon to know when they are at risk and should synchronize, or are
safe and don't need to. So they always synchronize.
That said, there are some smart pointers that have little
overhead, not anywhere near what you are thinking of.
But you don't know what I'm thinking of :o). Anyhow, referring us to
credible experiments would always help.
d) The code uses lock-free programming that make it hard to devise and
implement algorithms for deterministic storage reclamation.
I wouldn't know about it being hard to implement them but you can reuse
implementations once you or someone else has done them.
They can be as hard as years of research, as has happened. In contrast,
Java has lock-free components in its standard library now.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]