[boost] Re: "Non-standard" bits of SGI STL

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-09-08 20:42:55

>> 
>> - different policies: SGI extentions are in namespace std, Boost 
>>   libraries are in boost
>
> Yes, although changing to have boost::slist and boost::hash_map is a
> reasonable answer to that one.

Actually, STLPort can be configured to put everything in namespace STLPort.
We could always import those names into boost via using-declarations.

>> - you may just download the whole thing (SGI STL or STLport) and
>>   use it over your vendor's STL
>
> Correct - but aren't there issues with how the SGI STL interacts with other
> non-STL portions of vendor libraries (eg, iostreams)? I have no hard
> evidence of this, but I recall seeing something to that effect.

Only when you try to do the overlay without putting STLPort in its own
namespace. In any case, the STLPort will soon include its own iostream
implementation, so that will be a non-issue. In short, most of the problems
cited here are easily solved.

>> - if you have the SGI STL installed, these files (povided by
>>   Boost) could conflict if what you suggest is done
>
> Possibly, although I would hope that we could avoid that.
>
> However, having looked at the SGI implementation, I don't think that the
> slist and hash_map implementations could be extracted in a practical manner
> (the inter-dependencies between files is too great). While I still think
> that a non-SGI slist and hash_map implementation could be useful, I don't
> think the advantage is worth the effort. Especially as that effort could
> probably be better spent on implementing other things.

That job is likely to be difficult and not worth the effort, just as you
say. If you want slist and hash_xxx, the best way to get it in a
non-intrusive way is by using the STLPort in its own namespace. Importing
the names into boost at that point seems a bit redundant, no?

-Dave