std.allocator needs your help

[Andrei Alexandrescu]

On 9/22/13 9:19 PM, Manu wrote:
> On 23 September 2013 13:01, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
> wrote:
>     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?

As I just wrote in my previous post, the two mistakes in C++'s allocator 
design are:

1. Allocators are parameterized by type.

2. Allocators cannot have state.

I fix both.

>     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.

There are possibilities, which I hope to get to soon.

> 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.

Sean has already done that. The current GC is entirely replaceable (and 
in particular extricable).


Andrei