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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-08-27 06:21:58

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.

>> 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.

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.

> 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.