[RFC] Removal of allocator::construct / destroy vs our containers
Howard Hinnant
hhinnant@apple.com
Fri Apr 27 00:23:00 GMT 2007
On Apr 26, 2007, at 6:28 PM, Paolo Carlini wrote:
> Hi,
>
> in Oxford the removal of those allocator members has been decided.
> Immediately, people figured out that, for compatibility with
> existin user code a good path would be not actually removing the
> members from the delivered allocators, but stop as soon as
> possible calling those member functions from the containers (in
> fact, the *current* standard, nowhere mandates that those members
> must be called): certainly, in the case of v3, that would mean a
> nice semplification of stl_construct.h, stl_uninitialized.h and
> many container headers. It would also mean, unless i'm badly
> confused, not risking at all passing around by value allocators
> only because allocator::construct and destroy are non-constant
> members.
>
> Can you imagine problems with such a plan? Do we have principled
> reasons to delay it to when a full C++0x implementation of the
> library will be delivered?
This sounds like the beginnings of a good plan. I just wanted to add
one note of caution: The LWG subgroup decided to eliminate these
members of allocator. However the full committee slapped us down and
said we were moving too fast (and with good reason). So it isn't a
done deal yet. We may well do this in Jul. or Oct. But we haven't
done it yet, and I've seen committees turn on a dime. I think having
a plan in place is a very good idea. But we might not want to
execute the plan yet.
-Howard
More information about the Libstdc++
mailing list