std.allocator needs your help

[Manu]

On 23 September 2013 13:01, Andrei Alexandrescu <
SeeWebsiteForEmail at erdani.org> wrote:

> On 9/22/13 7:45 PM, Brad Roberts wrote:
>
>> I think the question he's asking, which a lot of people are anxiously
>> anticipating is... how does the intersect with the parts of the language
>> and core libraries that have been blocked (for a loose definition of
>> blocked) waiting for the allocator design.  Primarily, but far from
>> exclusively, the container library.
>>
>> Yes, the allocator design is clearly a lower level component, but it's
>> also far easier than the integration with the language and libraries.
>>
>
> Containers and other objects that want to allow customization of their
> allocation would be parameterized during compilation with an allocator
> type. Functions that need to allocate memory may similarly accept a
> parameter of allocator type.
>

You've just described C++ verbatim.
And you've previously agreed that C++'s approach totally failed. Can you
explain how this is different from C++, and how it solves the issues that
defeated that design?

One possibility I'm keeping in mind is that of defining a dynamic interface
> (i.e. in the OOP sense) for a global allocator. Then people can globally
> change what allocator must be used for operator new invocations.
>

Right, this is getting warmer. It's a stark contrast to what you suggest
above though, and when I try and think this through, it gets very complex,
very fast.
I can't imagine how such a system could ever be declared safe. However,
this is more or less what I want. I don't know how to reconcile the 2
requirements.

How much have you thought on this? This is where I think some serious
creativity will need to be applied...

Following this train of thought, I can imagine a really nice end goal would
be that the existing GC is effectively plugged in as a library, and people
can easily substitute it for their own GC if they want/need to.

The work at the level described so far is quite orthogonal on these high
> level choices. Right now it's all about a statically-typed allocator that
> is good at allocating and deallocating octets.
>
>
> Andrei
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130923/b5d0fa81/attachment.html>