This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] Removal of allocator::construct / destroy vs our containers
- From: Howard Hinnant <hhinnant at apple dot com>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Thu, 26 Apr 2007 20:23:19 -0400
- Subject: Re: [RFC] Removal of allocator::construct / destroy vs our containers
- References: <463127A8.9050804@suse.de>
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