std.container and classes

[Jacob Carlborg]

On 2011-12-21 08:53, Jonathan M Davis wrote:
> 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.

I was thinking if there were good uses for "delete" and "scope" they 
could stay. I think the "dispose" method in Tango makes them more useful.

> 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

I sounds like a struct is what should be used, it will be most flexible 
as well.

-- 
/Jacob Carlborg