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.

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 its own iostreams, which means your code do not use any part of native C++ standard 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.

For the most modern compilers which implements Koenig lookup properly, "wrapper mode" w/o STLport iostreams may not be available due to ambiguities during namespace lookup. Example: gcc-3.0.