<div dir="ltr">On 23 September 2013 13:01, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9/22/13 7:45 PM, Brad Roberts wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the question he's asking, which a lot of people are anxiously<br>
anticipating is... how does the intersect with the parts of the language<br>
and core libraries that have been blocked (for a loose definition of<br>
blocked) waiting for the allocator design.  Primarily, but far from<br>
exclusively, the container library.<br>
<br>
Yes, the allocator design is clearly a lower level component, but it's<br>
also far easier than the integration with the language and libraries.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>You've just described C++ verbatim.</div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>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.</div><div>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.</div>
<div><br></div><div>How much have you thought on this? This is where I think some serious creativity will need to be applied...</div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<span class="HOEnZb"><font color="#888888"><br>

<br>
<br>
Andrei<br>
<br>
</font></span></blockquote></div><br></div></div>