std.container and classes

[Jacob Carlborg]

On 2011-12-21 06:07, Jonathan M Davis wrote:
> On Monday, December 19, 2011 08:54:00 Jacob Carlborg wrote:
>> The Tango runtime has added a new method in Object, "dispose". This
>> method is called when "scope" is used or "delete" is explicitly called.
>> I don't know if that would help.
>
> That sounds a lot like using clear, though clear doesn't free memory unless
> the finalizer does (and I'm not sure that managing memory with finalizers
> actually works right now; there were issues with that previously - but it
> might have only been GC memory, so perhaps malloc and free would still work).
> The issue with them is escaping references. You can easily end up with
> references to data which has been destroyed. It also makes them harder to pass
> around unless you essentially wrap the container in ref-counted struct.
>
> The lifetime of the container must be managed if you really want to be able to
> use custom allocators or have the container be as efficient as possible with
> regards to its memory usage in the general case. With a struct, it manages
> itself. It can do whatever it wants to with memory internally, and the
> combination of its constructor, postblit constructor, and destructor allows it
> to take care of it itself and clean up its memory when it's destroyed. You
> also don't have issues of stuff referring to a container which doesn't exist
> anymore (unless you add pointers to the container into the mix and then move
> or destroy the container).
>
> With classes, if they're owned by the GC, then it's the GC that manages their
> lifetime. It destroys them when they're no longer referenced and it runs a
> collection cycle. You have no control over its lifetime, and even if it tries
> to manage its memory internally on some level, that memory won't be cleaned up
> until the GC collects the container itself. So, if you want to manage the
> lifetime of the class, you can't use a naked reference anymore. You need a way
> to get the GC to collect it, or you need to have it somewhere else other than
> the GC heap.

With "dispose" it would give you the option to control the lifetime of 
the object, in some cases.

> If you use something like Scoped, then its lifetime will be tied to the scope
> that it's in, but you risk references to it escaping, and limiting the
> container to a particular scope could be far too limiting anyway. That being
> the case, if you want to use an allocator other than the GC for the class
> itself, then you're probably going to have to stick it in a struct. That
> struct could then manage the container's lifetime on some level. It would
> probably have to use ref-counting and then call clear on the container when
> the ref-count hits zero. That should then allow the container to at least
> clean up its internal memory, assuming that that's not on the GC heap, but
> unless you use emplace on non-GC heap memory, the container itself still can't
> be collected until the GC collects it (since clear destroys it but doesn't
> free its memory). Not to mention, if you're using a ref-counted struct to hold
> a class in order to manage that class' lifetime, why on earth did you make it
> a class in the first place?
>
> If what you're suggesting with dispose is that it would act like clear except
> that it would actually free the container, well that pretty much goes against
> the direction that we've been trying to go with the GC, which is to not have
> the programmer explicitly freeing anything on the GC heap (which is why delete
> is being removed from the language).

I thought that one of the problems with the GC and memory was that you 
can't rely on when/if the destructors are called. With "dispose" it 
would give the developer a reliable method to cleanup resources, 
assuming "scope" or "delete" is used.

> I really think that if we want deterministic destruction of containers, they
> need to be structs. And if we want to use custom allocators with containers, I
> don't see how we could reasonably expect them to be of much use unless we're
> expecting that programmers will explicitly call clear on them when they're
> done with them. So, while the fact that containers need to be reference types
> does imply that classes are the way to go, I think that we're going to have to
> go with structs if we want their memory management to be more efficient than
> simply letting the GC handle it.
>
> - Jonathan M Davis

I was thinking that classes could be the safe and default but and 
scope/delete could be used as an optimization.

-- 
/Jacob Carlborg