This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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]

status on the allocator work


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


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