STLport and Vendor's C++ Library
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 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
To resolve this namespace conflict, after long experiments,
it was decided to put STLport into its own namespace "_STL::".
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.
Table of Contents
Copyright 2001 by STLport