Vote on region allocator

[Andrei Alexandrescu]

On 9/24/11 9:33 AM, dsimcha wrote:
> On 9/24/2011 2:10 AM, Andrei Alexandrescu wrote:
>> On 9/23/11 22:30 CDT, dsimcha wrote:
>>> On 9/23/2011 11:25 PM, Robert Jacques wrote:
>>>> On Fri, 23 Sep 2011 15:53:46 -0400, Jonathan M Davis
>>>> <jmdavisProg at gmx.com> wrote:
>>>>
>>>> No. I cannot build an efficient and safe appender on this API.
>>>
>>> The resize() fix you requested is going to get implemented. I just
>>> haven't actually added it yet.
>>
>> Then we might be hasty to vote this in. Ideally Phobos should be
>> integrating tried and true APIs.
>>
>> I wish we voted allocator in once it's used throughout std.container to
>> great effect.
>>
>>
>> Andrei
>>
>
> I see your point, but at the same time this does create a
> chicken-and-egg problem. The use case that inspired me to work on
> allocators is much simpler: Allocating simple temporary objects in
> performance-critical functions. I don't have any plans to do containers
> and I don't know of anyone else who does in the short term. Is there a
> way to avoid waiting indefinitely to get allocators into Phobos?

I plan to work on containers, and part of the work is to integrate 
allocators.

There are two basic paths from here. One is to make the allocator a 
template parameter a la STL. The other is to define a dynamic allocator 
interface and use it.

Making the allocator a part of the container type would go the STL way, 
and STL allocators are essentially a failed experiment. I'm only 
partially clear on why it has failed, but it does seem that part of the 
reason was making the allocator a template parameter.

Defining and using an allocator interface would have a small speed 
impact (i.e. allocation would entail an indirect call) but I think that 
would be acceptable.


Andrei