gcc-2.95 and SGI STL 3.2

[Benjamin Scherrey]

"Martin v. Loewis" wrote:
> 
> > >> STL 3.2 has one very important advantage (at least in things I'm
> > >> involved in) - it is thread-safe.
> [which class?]
> > <string>, see the thread starting with
> > http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html
> 
> In that case, updating STL won't give you anything: gcc does not use
> <string> from STL. I don't know what the rationale is, but I
> personally prefer the multithreading bug be fixed, instead of using a
> completely different implementation.
<rest snipped>

	Regarding the latest SGI STL, I had been working under the assumption
that it was planned to be included in the next major egcs release
(presumably gcc-2.95). Its my impression that it will break binary
compatibility which seems to be the consensus here as well. I think
its kindof a now or almost never decision isn't it? 2.95 is going to
be a major change and breaking old stuff might well be expected
although screams will certainly ensue regardless. Should we not then
expect that future releases will (almost) never (or certainly not for
a very long time) break binary compatibility? If so then that would
make integration of STL 3.2 something that might never be feasible in
which case we are now choosing to be "left behind" in the SGI tree. Is
that important to egcs developers/users? I really don't know but it
doesn't strike me as a good thing at first impression. The only other
major opportunity for integration I can think of is when the new
c++stdlib is finally integrated but I don't foresee that happening
anytime this year at its present rate of progress.

	I'd appreciate any corrections to my current impressions that others
more knowledgeable than me (that's pretty much all of you) might have
to offer.
	
	thanx & later,

		Ben Scherrey