Contents
Introduction About STLport SGI STL Base STLport Story STLport Features Portability Debug Mode Thread Safety Exception Safety Getting Started Download and Install Select Streams Mode Compiling with STLport White Papers Release Notes READMEs Interface with std:: Wrappers Config manual Regression Test Exception Test Feedback Bug Reports Forum Appendix Acknowledgements Your Free Licence
| # 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.