On 9/22/13 9:19 PM, Manu wrote:
On 23 September 2013 13:01, Andrei Alexandrescu
<[email protected] <mailto:[email protected]>>
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
