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: Paolo Carlini <pcarlini at suse dot de>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Fri, 27 Apr 2007 13:22:52 +0200
- Subject: Re: [RFC] Removal of allocator::construct / destroy vs our containers
- References: <463127A8.9050804@suse.de> <4631DA16.8020604@redhat.com>
Hi Benjamin,
in Oxford the removal of those allocator members has been decided.
Also the member function address...
Indeed, but we are not using it ;) Actually, your point makes for an
interesting detour: shall we take the address issue seriously? I mean,
shall we fix "somehow" the library to not use operator& and instead
obtain "by hand" the address of the objects? That change is not
necessary in the current standard, but I understand in the next one
objects will be allowed to freely overload operator&. Actually the
reason I didn't seriously propose something yet, is that, sorry for
being explicit, boost::addressof seems so ugly, the last time I saw it,
exploiting *2* reinterpret_cast :( Should this get front-end support?
unless i'm badly confused, not risking at all passing around by value
allocators only because allocator::construct and destroy are
non-constant members.
do you mean allocate/deallocate here?
No, construct and destroy. Those are not const members and that causes
problems. One very nice reason to remove both, I hadn't seriously
understood until a few days ago.
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.
Paolo.