STLport and Vendor's C++ Library

Modern compilers come with more or less complete ANSI standard C++ library.  Below, term "native" is being used to refer to standard C++ headers and object code libraries supplied with the compiler.

The problem that arises when you want to use STLport with them, is that putting STLport into namespace std:: may violate ODR(One Definition Rule). This can happen if some parts of native library (such as string, locale, iostream) are instantiated already and compiled into native runtime C++ support libraries.
Example : Visual C++ 6.x

In practice, if the compiler supplies  new-style <iostream>, you have this problem almost for sure - typically that means you have some <string> stuff compiled into native C++ object library. The clash can happen even if you do not utilize new-style iostreams.

Even if you use STLport with SGI iostreams, which means your code do not use any part of native C++ library, you may still encounter clashes at link stage. Just magine using 3rd-party lib which was compiled with native library.

To resolve this namespace conflict, after long experiments, it was decided to put STLport into its own namespace "_STL::".
This provides seamless drop-in compatibility and ensures no conflicts are ever possible.

To provide more portability for your code and to make sure you use _STL:: components, not the native std:: one, STLport provides macro redefinition of std:: into _STL::. This is completely transparent to the user.

As STLport code uses namespace different from std::, it never clashes with native library - neither at compile nor at link time.