This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New STL & egcs
- To: egcs at cygnus dot com
- Subject: Re: New STL & egcs
- From: Nathan Myers <ncm at cygnus dot com>
- Date: Thu, 09 Jul 1998 17:16:36 -0700
- Newsgroups: cygnus.egcs
- Organization: http://www.cantrip.org/
- References: <14102.899952980@hurl.cygnus.com>, <199807091455.HAA04686.cygnus.egcs@atrus.synopsys.com>
Joe Buck wrote:
> The SGI STL v3.1 has code that conflicts with existing libstdc++ code
> in at least two places: the string class, and the exception classes.
> Both SGI and the existing libstdc++ provide versions.
I don't know of any reason to prefer the existing exception classes
over the ones in SGI-STL.
> The SGI string
> class is superior in that it conforms to the standard and our existing
> class does not.
>
> To properly make these decisions we need to know more about the status
> of the replacement libstdc++. Can Ulrich Drepper or Jason Merrill comment
> about the status? When will a version be available for testing? If you
> want to keep it private, should we use the SGI string class or not?
>
> (I'm for dropping the existing string and using the SGI one).
There are valid reasons to support both strings. The existing one
(and the rewritten version of it) should be a lot faster and smaller in
non-threaded applications. The rewritten version should also be faster
in threaded contexts where an atomic decrement-and-test is available,
or where memory is dear and memory allocation is slow.
The SGI version does not rely on reference-counting, and instead copies
the string contents promiscuously. It might be faster in a threaded
context in which reference-counting is expensive but both memory and
memory allocation are (very) cheap.
It will be sensible to offer a config-time option. However, for 1.2
I would simply leave string (and perhaps exception) as-is, and simply
update the remaining components.
Nathan Myers
ncm@cantrip.org