Re: [boost] stl extensions

From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-10-01 06:08:02

Terje Slettebø writes:
 > >From: "Anthony Williams" <anthwil_at_[hidden]>
 > 
 > > Toon Knapen writes:
 > >  > I've been using my own std::is_sorted, std::iota etc. on
 > compilers/stl's that
 > >  > do not provide these extensions (snippet below). OTOH, I've seen that
 > >  > boost/detail/algorithm does the same thing (but here all these are
 > defined in
 > >  > the boost namespace, not the std namespace).
 > >  >
 > >  > Now I think it would be interesting to provide these extensions for all
 > stl's
 > >  > that do not include these to improve portabilitity of C++ programs.
 > Should
 > >  > boost/detail/algorithm.hpp be used for this (but in that case the
 > header
 > >  > should directly be in the boost includes and not in a 'detail'
 > subdirectory)
 > >  > or would it be better to define these in the std namespace ?
 > >
 > > It is undefined behaviour to add them to namespace std, so they had better
 > > live in namespace boost.
 > 
 > If this is the case, what about the SGI STL/STLPort extensions to STL? Is
 > the clause about undefined behaviour to guard against possibly name-clashes,
 > perhaps (which SGI STL/STLPort may handle, but where an additional library
 > may not guard against)?

The clause is there to allow the implementation to add any names it likes to
namespace std, in support of the rest of the library, without having to worry
about name clashes or overload resolution issues from names introduced by the
user. An implementation may also provide the user with documentation on any
additional names, thereby making them a documented extension.

To the extent that STLPort is part of the implementation, it is permitted to
provide any names it likes in namespace std, provided they don't clash with
those supplied by the rest of the implementation (such as the compiler minimal
support library for std::exception/std::type_info).

However, boost is definitely not "part of the implementation", it is "just"
another library, so it should not add any names to namespace std. (Except that
I think that adding names that should be there anyway, as specified by the
Standard, to improve the conformance of an implementation, is probably
justified)

Anthony