This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PATCH: use construct and destroy from user-provided allocators
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Matt Austern <austern at apple dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: 27 Jul 2004 12:56:35 +0200
- Subject: Re: PATCH: use construct and destroy from user-provided allocators
- Organization: Integrable Solutions
- References: <451DD07A-DF86-11D8-9F91-000393B2ABA2@apple.com>
Matt Austern <austern@apple.com> writes:
| As discussed earlier, this patch makes STL containers use their
| allocators to construct and destroy elements. (i.e. using the
| Allocator::construct() and Allocator::destroy() member functions.)
| Test cases included.
|
| There are a lot of lines of changes, but it's really pretty
| straighforward: I define versions of the uninitialized_* functions,
| and _Destroy, that take allocators as arguments. I overload them so
| that when the allocator is std::allocator() they behave the same way
| as the old versions did.
|
| Two things to notice about this patch.
| 1. There is a cost to doing this. Right now, there are cases where we
| optimize initialization to memset/memmove and there are cases where we
| optimize destruction to nothing. If we're committing to using
| construct/destroy for user-provided allocators, that means we can only
| do these optimizations for std::allocator. I think this is an
| acceptable cost, since people who provide their own allocators ought
| to have a reason for doing it, but it is a cost.
| 2. I'm only using construct() and destroy() for containers' elements.
| I think that's all the standard demands, and it's probably all that
| users really want. Conceivably we should also be using construct()
| and destroy() for other things we allocate (pointers, nodes, etc) but
| we can leave that for another day, if ever.
|
| OK to commit to mainline?
Yes. Thanks!
-- Gaby