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