[boost] Re: what happened to allocators in boost?

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-08-29 01:46:40

On Wednesday, August 27, 2003, at 2:21 PM, Peter Dimov wrote:

> Daryle Walker wrote:
>>
>> That's an invalid argument, since the STL containers give you a 
>> default value for the allocator argument, which makes containers work 
>> out of the box, and the default is "for free."
>
> I'm afraid it is not. The allocator parameter has a cost. It (a) 
> prevents some very useful optimizations, (b) implementations that take 
> it seriously (i.e. respect ::pointer, ::construct etc) make me suffer 
> a measurable abstraction penalty.

I wasn't talking about abstraction "costs," my "for free" phrase was a 
counter to your (sarcastic?) statement about library vendors providing 
a 90% solution and then charging for the remaining 10%.

>>> Bugs that have no workarounds are always fixed first. :-)
>>
>> You're making a worse assumption here.  Who says that the need for a 
>> different allocator class is because the default one 
>> has-bugs/is-slow/plain-old-sucks?
>
> I say that the primary motivation to customize memory management 
> details is that the default memory manager is slow.

Just because you dislike the (so-called-by-you) primary motivation, you 
want to ban all other motivations?

> The standard allocators have a somewhat different story. They were 
> originally intended to encapsulate the memory model, not the memory 
> management details; this was in the near/far days. The original STL 
> did its own memory management (free lists) independent of the 
> allocator argument.
>
> Someone that has actually been present at the relevant meetings can 
> fill the details why the allocators are now what they are (I'm tempted 
> to use Alexander Terekhov's favorite characterization here :-)).
>
>> There can be an orthogonal need for a different allocator class, 
>> which no improvement on the default one can fix.
>
> Oh yes, there "can be". And there "can be" a need for something else, 
> too.

Drop the sarcasm.  I think some of the embedded-system guys around here 
gave examples.  I'll give another one.

Some operating systems have "evolved" several memory APIs.  (I'm not 
making this up, look at pre-X Mac OS.)  The C++ library provider maps 
the C++ memory APIs to one of the system memory APIs.  You could wrap 
calls for the other APIs with new allocator classes.  And before you 
counter with "why need the other memory calls at all, just substitute 
the main memory API," there are other APIs can only accept memory from 
a certain memory API.

>> In this case, the Java user is 100% screwed since they can't change 
>> the memory manager at all. [...]
>
> My point exactly. This is why the Java memory manager beats C++'s 
> memory manager in the long run, because the user can't fix it.

As I said, performance isn't the only reason for making a new 
allocator.  The vendor may make performance improvements, but probably 
not orthogonal features.  (Are you proposing that the vendor should 
provide a "Swiss-army-knife" solution every time a suggestion is made.)

There is also the latency concern.  This is true even if (or especially 
if) your problem with the default allocator is performance.  You can't 
always make the user with performance concerns wait until "the vendor 
feels like updating."

Daryle