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: Benjamin Kosnik <bkoz at redhat dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, austern at google dot com
- Date: Tue, 01 May 2007 11:36:41 +0200
- Subject: Re: [RFC] Removal of allocator::construct / destroy vs our containers
- References: <463127A8.9050804@suse.de> <4631DA16.8020604@redhat.com> <4631DD0C.1060706@suse.de> <4632B1BE.5020604@suse.de>
Paolo Carlini wrote:
Hi,
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?
Not that I can see. You're still keeping the C++98 interface.
At the very least, I think this is worth having a patch for, just so
that somebody can indicate that this has been implemented and the
issues were not severe.
Excellent. I will prepare one.
In practice, the below (+ removal of a few tests only exercising
construct / destroy) passes the testsuite and appear to work well.
Mechanical changes, as expected.
All in all, I'm starting lo like this clean-up a lot. As already
mentioned, we also avoid passing around allocators unnecessarily.
I'm thinking, maybe the risk would not be that big: for one, nowhere the
standard says the containers must call allocator::construct / destroy.
Moreover, the current consensus in the LWG is that there isn't much
point in calling them. Therefore, even if, for some reason, eventually
they will be remain in C++0x, so what? In any case, we would mention the
implementation change in the release notes.
What do you think?
I think we should go ahead with this transformation. It is conforming to
C++98 as well as forward-looking to C++0x: seems like an obvious win.
I've cc'd Matt on this in the hopes that he'll take a gander at this. It
certainly seems to me that this is exactly what he intended.
As part of this, I noticed that there are no construct or destroy
exports from the libstdc++ shared library, because 1) these functions
are inline and small, 2) mostly unused. So, strictly binary-wise, this
change doesn't break the ABI. It is a change to the API however, and a
removal of public member functions so we cannot go through and kill
these members in the ext/*_allocator.h files.
It would probably be worth going through those files and adding in
// XXX GLIBCXX_ABI Deprecated
markers next to these member functions, to make it more obvious as to
our intentions with the next ABI break.
-benjamin