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
> >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.
* std::allocator is required to use ::operator new, which is replaceable;
* std::allocator is specializable by the user per 18.104.22.168/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 22.214.171.124/1 is
not obvious. :-)
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk