On Fri, 2005-01-14 at 16:56 -0700, Luke Palmer wrote:
> > I thought C++ only guaranteed destruction (on return or exception) for
> > objects which were directly on the stack.
>
> That's true, you have to explicitly delete most memory. I was actually
> referring to the template refcounting classes that I use all the time:
>
> void foo() {
> ref<Image> image = new Image("somefile.jpg");
> image->draw();
>
> // image will be cleaned up automatically
> }
>
> Here, C++ manages only to refcount objects (or rather, pointers) that
> are declared using ref<> instead of *. In a dynamically typed VM this
> isn't possible.
Yeah, but the ref<> object is directly on the stack, and destruction of
that, and thus decrement of the refcount, is guaranteed. Um.
The example you described destroyed a ref within a sub, and then assumed
that the object refed would be destroyed at scope exit.
This is incorrect: the object refed should be destroyed when the ref is
destroyed in a general refcounting GC system.
Anyway, this led me to the (useful?) thought that you could delink the
concept of timely GC and destruction at scope exit by registering
atexit() or atleave() code on a scope (like finally{}) which explicitly
undef'd registered PMCs. That way you would be able to guarantee
destruction even if the PMC was still ref'd, which is probably more use
for things like critical section locks than just relying on a
side-effect of the GC, and is certainly easier to implement since it's
just a flag on the lexical in the pad.
S.
