On Fri, 04 May 2012 13:59:02 -0400, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Friday, May 04, 2012 13:38:24 Steven Schveighoffer wrote:
Allocation and destruction are orthogonal to the problem. For example,
in
working on the new std.io, I've had to make RefCounted!(class) work, All
I do is allocate the class data into the C heap.
It's not orthogonal if you want the allocation to be internal to the
type and
not have to worry about wrapping the container in a struct to actually
get it
to deallocate properly.
Allocation of the container itself is a different problem than allocation
of its internals. I think you are confusing the two.
For example, I can have a red black tree that allocates all its elements
using malloc, then allocate the class itself on the stack using scoped so
it becomes deallocated after exiting the scope.
Or I can use malloc for internal allocation, and use new to allocate on
the heap, and let the GC clean up the tree (and the malloc-based allocator
stored in the class cleans up its elements).
For instance, you can allocate a class with malloc,
but without a wrapper, you're going to have to keep track of the fact
that it
was allocated with malloc and make sure that you destroy it and free it.
Yes, and this has nothing to do with the custom allocator needed to
allocate its elements. The container owns the elements, it doesn't own
itself. Even a struct can be allocated on the GC heap.
As I understand it, Andrei intends for the custom allocators to be
dynamic,
which means that the type of the container will be the same regardless
of the
allocator used. And if that's the case, I don't see how you can safely
use
classes as containers without always wrapping them in structs. And if
you're
going to do that, why whould you make them classes in the first place?
Again, these are orthogonal problems. Who allocates and owns the
container is different than who allocates and owns the elements.
The container is responsible for cleaning up the elements (via the
allocator it is handed), someone else is responsible for cleaning up the
container. It could potentially be the same allocator, but it also could
potentially be something completely different.
The only requirement is that the allocator *must* live at least as long as
the type itself (if you are going to do dynamic allocators). This rules
out a simple GC-allocated reference type as an allocator, but the
container itself can be GC allocated.
Dcollections does not currently use dynamic allocators, although it could
be made to do so. Currently, the allocator is a struct which is stored
inside the container.
-Steve
