std.container and classes

[Jonathan M Davis]

On Wednesday, December 21, 2011 08:44:10 Jacob Carlborg wrote:
> 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 was thinking that classes could be the safe and default but and
> scope/delete could be used as an optimization.

Well, both delete and scope are going away, so std.typecons.scoped would have 
to be used instead, but that only really works for local variables. It would 
probably work for a member variable as well, but in both cases, you have to 
worry about the class going away when Scoped goes away and how that affects all 
of the references to it.

If, on other hand, you use a ref-counted struct, it takes care of itself 
without the risks of the container going away while references to it still 
exist (unless you keep a pointer to it somewhere instead of the ref-counted 
struct). So, ref-counted structs would be much safer, and they could use 
advanced memory management internally by default, making them more efficient by 
default.

What I really don't get, however, is how custom allocators would be of much 
use for classes unless the entire class is allocated that way (in which case, 
it's probably going to end up in a struct of some kind anyway unless you want 
the same issues that you get with scoped), since if the class is on the GC 
heap, its internal memory management couldn't release any of it until the 
container is collected by the GC. So, it seems to me that the desire for 
custom allocators would favor the use of ref-counted structs over classes.

- Jonathan M Davis