This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: use construct and destroy from user-provided allocators

Matt Austern <> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]