Re: [boost] Re: "any" suggestions

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
would
>  >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 17.4.3.1/1;
* 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 17.4.3.1/1 is
not obvious. :-)

--
Peter Dimov
Multi Media Ltd.