Re: Future of C++
On Aug 14, 7:59 am, David Abrahams <d...@boostpro.com> wrote:
[...] I thought I gave a pretty good explanation of the
problem above, and it's hard to think of anything to add to it that
would help you understand the problem. Maybe an example would help:
// this class is threadsafe!
struct queue
{
void push(int);
int pop();
private:
...
mutex m; // note: the fact that queue contains a mutex is
}; // an implementation detail; not part of the interface.
The fact that it has a mutex may be an implementation detail, but the
fact that the destructor is non trivial is part of the interface: the
user can know this via std::has_trivial_destructor<>. A simple rule
might be to formally allow garbage collection only for objects that
have trivial destructors. This would unfortunately rule out all std
containers, unless they could optionally run in 'gc' mode (an extra
template parameter?). Maybe a trait like
has_almost_trivial_destructor<> which is true if the only thing the
destructor does is calling delete or other destructors that only call
delete (hard to implement I guess). Probably the way to go is a
destructor attribute like [[when_gc_disabled]] that would make the
destructor '= deleted' when the garbage collection is active.
[snip]
When you introduce GC into the language, clients suddenly get the
freedom to intentionally "leak" most objects... but not mutexes, queues,
or simulations. [GC wouldn't call destructors (seehttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1943.pdf) and
even if it did, there's no guarantee that it would ever run. There are
myriad other reasons that destructors cannot be called from GC cleanup.]
So the fact that they manage a non-memory resource is no longer an
implementation detail of queue or simulation.
Then maybe it shouldn't be. Although for many programs you do not need
to know it.
IMVHO the biggest benefit of gc is not to help those programs that
forget to call delete, but to help those other programs that really do
not know when to call delete (short to reinvent an ad-hoc garbage
collector). shared_ptr helps a lot in these cases, but as a
significant space and performance cost and doesn't handle cycles
(shared_ptr is still very useful when you need to call non trivial
destructors of course).
Not to mention the fact that GC'd heap is often faster than a
traditional heap.
--
gpd
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]