std.allocator issues

[Andrei Alexandrescu via Digitalmars-d]

On 02/19/2016 09:21 PM, Steven Schveighoffer wrote:
> I'm trying to use the std.experimental.allocator API more in my new io
> library, and I'm having a few stumbling points:
>
> 1. GCAllocator only allocates void, which is marked as containing
> pointers. This is no good for a stream buffer, and can severely harm
> performance.

Yah, some work on the porcelain is needed. There is TypedAllocator and a 
few primitives that provide a start.

> 2. GCAllocator provides a free function. There's no way for me to tell
> generically that it's OK *not* to free allocations, though. I understand
> we should provide a hook if there exists a way to do so, but there needs
> to be a way to free this. I'd prefer not to free data if it's not
> strictly necessary.

Indeed that's an interesting matter. I was thinking of simply having two 
types - GCAllocator and GCSafeAllocator that doesn't have free (and 
probably other unsafe functions such as realloc). They'd use alias this 
to share implementation.

> 3. GCAllocator needs a mechanism to specify type info for allocations so
> the dtors are properly run in the GC. While not critical for my
> purposes, this is going to be very important, and should be figured out
> before merged into mainline Phobos.

That interface between types and the GC-based allocator is at this time 
embryonic. I'll need at some point to sit down and figure out a strategy 
that works for GCAllocator but also for other allocators.

> 4. Various functions in std.allocator take a ref void[]. This is no
> good. I don't want to store a void[] in my type, because that's not very
> useful, but if I want to reallocate, or expand, then I need to do a
> dance where I copy the array to a void[], do the reallocation, and then
> copy it back (if successful). This fully defeats the point of having a
> ref in the first place. I understand there are wrappers that do this for
> reallocating, but I want to use the other tools as well (expand in
> particular). But principally, to have an API that is mostly unusable
> seems unnecessary.

Yeah, that's work in the porcelain - typed wrappers etc.

> I really do like the API, and it's fitting in quite nicely! I can work
> around all these at the moment, but I'd love to see these improvements
> in place before making official phobos.

Sounds good!


Andrei