Transforming a range back to the original type?

[Steven Schveighoffer]

On Fri, 04 May 2012 13:59:02 -0400, Jonathan M Davis <jmdavisProg at 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