Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-17 03:59:23

From: "Beman Dawes" <bdawes_at_[hidden]>
> At 02:54 PM 7/16/2001, Corwin Joy wrote:
> >And what exactly is the "downside" of providing a template parameter to
> >take
> >an allocator. It seems relatively easy to add & I don't see how it
> >degrade the existing functionality or performance of any.

This turns a non-template into a template. Sometimes non-templates are
better from an implementation hiding point of view.

> Allocators have been a disappointment. I'll guess that if the library
> working group were to do it over again, there would be quite a few people
> arguing for no allocators parameters in the standard library
> containers. Every addition parameter (when as complex a concept as
> allocators) adds to user confusion. One alternative is to just let the
> implementations do the right thing. The other is to fix allocators.

Unfortunately there is no conforming way for implementations to do the
"right thing" as I see the "right thing," namely, std::vector<T> to be the
vector of choice when I don't care about the specifics of memory allocations
but want the best performance.

Reasons include:

* std::allocator is required to use ::operator new, which is replaceable;
* std::allocator is specializable by the user per;
* a partial specialization of std::vector<T, std::allocator<T> > is
detectable because std::vector<T, A> is specializable by the user.

Whether this is a problem with the allocator concept or with is
not obvious. :-)

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at