std.allocator ready for some abuse

[Dmitry Olshansky]

25-Oct-2013 02:29, Brad Roberts пишет:
> There was a comment in an earlier reply that's very relevant to mine.  A
> good demonstration of the utility of these classes is how much of the
> current (and proposed) garbage collector can be replaced by using this
> module.  For that to happen, the code needs to actually live in the
> runtime (at least as things are currently layered).
>
> On 10/24/13 12:54 PM, Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> I know it's been a long wait. Hopefully it was worth it. The alpha
>> release of untyped allocators is
>> ready for tire-kicking and a test drive.
>>
>> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>>
>> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html
>>
>> Warning: this is alpha quality. Unit tests are thin, and there are no
>> benchmarks. Both would be
>> appreciated, particularly benchmarks to validate the gains (which I
>> speculate can be very sizable)
>> of custom-built, special-purpose allocators compared to traditional
>> allocators.
>>
>> I acknowledge I'm clearly in no position to evaluate this design. I
>> have been knocking around it for
>> long enough to have no idea how easy it is to get into it from the
>> outside, or how good it is. By
>> all signs I could gather this feels like good design, and one of the
>> best I've ever put together.
>> The allocators defined have an archetypal feeling, are flexible both
>> statically and dynamically, and
>> morph and combine in infinite ways.
>>
>> CAllocator and CAllocatorImpl make the link between the static and
>> dynamic worlds. Once an allocator
>> is assembled out of pieces and finely tuned, wrapping it in a dynamic
>> API is a snap.
>>
>> Please destroy! I've literally sweat as I'm sending this :o).
>>
>>
>> Andrei

Looks incredibly cool so far :)

Some thoughts:

- I don't like the name CAllocator. Whatever that C stands for it's 
ambiguous (Class, Cee, Caramel?).

- It may be only me but I _think_ it could be more useful to have a few 
specific interfaces then 1 fat CAllocator. I've come to dislike 
fat-interfaces with isSupported kludges but that's IMHO.

- I see that shrink primitive didn't make it... Well, on the upside the 
primitives count is really low.

- In description of chooseAtRuntime:
HeapBlock!chooseAtRuntime  --> HeapBlock!(Allocator, chooseAtRuntime)


-- 
Dmitry Olshansky