This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: stl_alloc.h
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: pedwards at disaster dot jaj dot com
- Date: Mon, 26 Nov 2001 20:41:51 -0600 (CST)
- Subject: Re: stl_alloc.h
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
> This file was next on my list to doxygenize. I'm discovering that it's
> chock full of SGI'isms, including comments. I am cleaning those up in those
> places which I know will not break things elsewhere, change the ABI, etc.
Apologies for being out of action last week. As someone that tried to
maintain SGI compatibility when he last hacked that file, your plans
sound good to me. I think all exposed names should match all the
uglification rules used by other parts of the standard library.
In addition to the issues you raised about the SGI STL: I would also
support removing all threading support other than the gthread path
(this is our abstraction layer and is portable to other compilers in
case anyone wants to raise that issue). Since there is a ``null''
gthread plugin, I would support making it the one and only code path
to radically simplify things. Supporting the older SGI
non-abstraction for mutex locking buys us nothing but pain. Keeping
the spin lock path could be useful if/when someone gets around to
looking at Nathan's proposal (it is getting high on my list), but it
is just as easy to get it from the last version of stl_alloc.h that
had it.
Regards,
Loren
--
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672