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>;
Table of Contents
Copyright 2001 by STLport