STLport.org - "Templates that fit"
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

Note for xlC & Visual Age C++ users


Known problems

Compiling

xlC & VAC++ require explicit template notation such as template_class<Param> where most others (conformant) accept just template_class (inside template method bodies, etc):

template <class Param> class template_class {
template_class foo() ; // error for xlC
template_class<Param> foo() // OK
.....
}

That is being worked around in this adaptation, but may cause problems when porting template code from other platforms.

Linking

Repository handling in this compilers is imperfect, so you may experience various problems on link stage. The problems are generally of two kinds : unresolved symbols and duplicate symbols. The latter problem is not fatal, since the symbols are weak in that case. It may cause unacceptable code bloat when it comes to large projects, however. To overcome this problem, for all IBM compilers, STLport 3.2 enables separate compilation with non-inline template members defined in .c file. Note : you should enable corresponding option in the compiler (/Ft+ or equivalent) to get use of this mode, as it is being enabled conditionally based on the presence of builin macro ___TEMPINC__.
When compiling templates splitted to *.h/*.c scheme, these compilers produce better results (around 50% code size reduction, less duplicate symbols). The problem with undefined symbols is also caused by imperfect repository handling, but it may require manual intervention. General rule is : if you get "unresolved symbol" errors, explicit instantiation will most likely help, for example:

Unresolved:
__default_alloc_template<0, 0>::allocate(unsigned long)
__default_alloc_template<0, 0>::deallocate(void*, unsigned long) >

To work around this problem, just instantiate __default_alloc_template<0,0> explicitly in some module:

template class __default_alloc_template<0,0>;

 


Copyright © 1999,2000 by Boris Fomitchev.    Last modified: July 14, 2000