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