Re: stl implementations--does anybody use SGI STL anymore?

[Larry I Smith]

Randy Smith wrote:
> 
> 
> Ulrich Eckhardt wrote:
>> Randy Smith wrote:
>>
>>> I am curious what the dominant stl implementations available are
>>> nowadays. 
>>
>>
>> Only one, the STL. In case you wonder, the STL (there is only one,
>> remember) has strongly influenced the C++ standardlibrary. With some
>> exceptions, it has been completely incorporated into the C++
>> standardlibrary in fact and there it resides next to IOStreams, the C API
>> and some other stuff.
>>
>>
>>> I've used the SGI stl implementation for quite a while alongside gcc,
>>> but a recent upgrade to gcc (using 3.4.4 now) will not compile the
>>> sgi stl, and it looks like non-standards-compliant code is the
>>> culprit. Browsing around using google, I could find very little
>>> information on sgi stl, so I'm guessing it has gone into disuse.
>>
>>
>> Right, soon after C++ was standardised, the meaning of the STL on its own
>> vanished.
>>
>>
>>> Although it has been several years since, I have experienced some
>>> pretty nasty multi-thread-triggered bugs in the gnu stl that were not
>>> problematic in the sgi stl (the bug had to do with inherent
>>> thread-safety problems in gnu stl's implementation of string creation).
>>
>>
>> Which bug number? Did you check if it got fixed? Or did you check if
>> it was
>> a bug at all and not just misuse?
> 
> I never looked for a number, but it was bug not a misuse.  I didn't have
> the option of upgrading our entire toolchain even if it was eventually
> fixed, so when we learned from others who experienced the same thing
> that SGI's STL implementation did not have the problem, we switched STL
> impls and didn't look back.
> 
> The problem was that string creation was inherently not thread-safe; if
> a thread was in the process of creating a string, switched out, and
> another created a string, the contents of the first string could get
> corrupted.  The SGI stl avoided this problem, although string creation
> was somewhat slower.
> 
> The problem was so expensive in terms of man-hours to identify (the
> software was on an embedded box and the bug exhibited itself only under
> extreme load) that all of us involved became leery (for better or worse)
> of the gnu c++ stdlib.  This was circa 2001-2002.
> 
> Thanks for comments.
> Randy Smith

You may find the FAQ on libstdc++ useful:

  http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html

FAQ items 3.7 and 5.6 discuss some thread issues.

The libstdc++ Home page is:

  http://gcc.gnu.org/libstdc++/index.html

Under the TOP-MOST (on the left) 'Documentation' link
you'll find 'BUGS', 'PROBLEMS', 'TODO', and 'RELEASE-NOTES'.

Regards,
Larry