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
