Re: Future of C++
on Thu Aug 14 2008, gpderetta <gpderetta-AT-gmail.com> wrote:
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<>.
The fact that something is discoverable doesn't make it part of the
public interface. If I don't document the fact that a class has a
trivial destructor, and will for all time, I rightfully expect to be
able to add a nontrivial dtor without breaking client code.
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?).
Where they couldn't contain objects with nontrivial dtors.
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).
Hard enough to be impossible. In general the compiler can't see the
dtor's implementation.
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.
So as you can see, it gets kinda messy when you try to shoehorn GC into
C++.
[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.
Maybe that would work for you, but personally I value encapsulation over
the advantages of GC.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]