Vote on region allocator

[Peter Alexander]

On 25/09/11 12:55 AM, Andrei Alexandrescu wrote:
> 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

I would like to say something here as someone that uses allocators in 
C++ every single day at my day job: STL allocators are useless and no 
one uses them in the way they were intended. Everyone I know defines a 
runtime polymorphic allocator that is used by all containers and then 
derives from that to implement different allocators.

The problems with STL allocators are listed here: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#std_allocator

It's a document by a large game developer, but none of the allocator 
complaints are specific to game development. Many of the same concerns 
are raised here: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf

Also note that even though we obviously care a lot about performance, 
we're fine with the cost of the virtual call on allocation. If you care 
about performance then you shouldn't be allocating often in the first 
place. We'd care a lot more about the code bloat caused by instantiating 
different templates for each different allocator we use.

In short, I believe that templating containers on their allocator would 
be a very poor decision. It was tried in STL and it failed miserably. 
Let's learn from its mistake.