std.allocator ready for some abuse

[Andrei Alexandrescu]

On 10/25/13 5:07 AM, Namespace wrote:
> On Friday, 25 October 2013 at 11:21:55 UTC, Jakob Ovrum wrote:
>> On Friday, 25 October 2013 at 10:02:08 UTC, Namespace wrote:
>>> On Friday, 25 October 2013 at 09:51:40 UTC, Maxim Fomin wrote:
>>>> On Friday, 25 October 2013 at 09:37:23 UTC, Namespace wrote:
>>>>>
>>>>> We would have then the possibility to manage our memory by ourself.
>>>>> One of D's promises is, that the GC can be disabled. Yes, it can,
>>>>> but then we have many many things which do not work. For example
>>>>> built-in arrays.
>>>>
>>>> Not only arrays, but classes, throwables, scope exits, new operator,
>>>> nested structs, etc.
>>>
>>> Thats right.
>>> But I often use temporary arrays, but I still don't like them because
>>> they are always consume so much GC memory. But with allocators that
>>> would end.
>>> Let us hope that Walter has the right intention and that Andrei
>>> design the allocators for this purpose.
>>
>> Why does it have to be the opaque druntime dynamic array? Why can't
>> you use the hypothetical (planned, rather) std.container.Array that
>> supports custom allocators, or a type of your own design?
>
> Because Array!int looks a lot more ugly than such a nice thing as int[].
> And if it is possible to change the allocator for some arrays, why
> shouldn't we implement it?
> The default allocator would stay the GC allocator. So if you don't want
> to swap the allocator of your arrays, don't do it.

Maintaining per-array-object allocators could be quite expensive. Two 
other possibilities are keeping one allocators for all array of a given 
type and of course keeping a global allocator for all arrays.

Andrei