On 23 September 2013 13:01, Andrei Alexandrescu <SeeWebsiteForEmail@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