This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
status on the allocator work
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Mon, 22 Dec 2003 23:34:28 -0600
- Subject: status on the allocator work
- Organization: Red Hat / Chicago
Matt correct me on this if I'm wrong.
Remaining container conversions:
rope
Remaining on the allocator classes:
1) Remove __simple_alloc, _Alloc_traits, all non-standard bits.
(including support for old-style allocators from the debug mode.)
2) Fix or remove __debug_alloc.
3) Fix __mt_alloc ctors, consolidate initialization in ctors, convert to
using new, try to remove some of the impossibly gross casting! It seems
to me that a lot of the internal data types could have ctors/dtors that
self-increment...
4) Convert __pool_alloc
5) Find better names for __pool_alloc, __mt_alloc, new_allocator. In
general, it looks like 3.4 is going to be a complete break from 3.[2,3].
This shouldn't be a surprise: it's been something that has been
documented and planed for months now. We should feel free to come up
with something good, and as clean as possible. Emphasis on clean.....
Then, I'm suggesting that the std::allocator be either __mt_alloc or
__pool_alloc, configurable. Before we make a decision, I'd like to check
in to the performance testsuite specific MT benchmarks. (This is
pending.) That way, data for different systems can be gathered.
Thoughts? I'm going to be a bit out of it for a bit, so anything not in
by the 23rd is fair game for others! I'll check in when I get back to
avoid working on stuff that has been started by others.
-benjamin