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
| # Notes for SUNPro C++ Users ## Common Notes For all SUN compilers, STLport 3.2 enables separate compilation with non-inline template members defined in .c file. That is supposed to help with code bloat, but does not make a big difference for SUN compilers. So, if having any problems with this mode, just turn off __STL_LINK_TIME_INSTANTIATION switch. ## Notes for SUNPro C++ 5.0 users ## Known problems #### Compiling Directory STLport/SC5/ contains some extra files SunPro C++ expects to see on the path. Make sure you put STLport/SC5 in your search path along with STLport main directory. You may encounter problems using `<iostream>` in mix with STLport `<string>, <stdexcept>` without defining __STL_USE_OWN_NAMESPACE. ## Known problems #### Bugs (Note for SUNPro C++ 4.2 or before) Note : in 3.2, proposed workaround is implemented for this bug for all relevant STLport code. However, please be aware of this bug because it might affect your own code. Perry R. Ross 3/12/99 pross@platinum.com The SunPro 4.2 compiler has a serious problem handling string literals passed as arguments to inline functions. Each time the dummy argument representing the string literal appears in the function, it receives a new address, just as if you'd typed the literal at that spot in the function. Normally this is harmless except for wasting a bit of memory, but if the function attempts to do any pointer arithmetic, it fails horribly. Here is a small program that duplicates the problem: #include <iostream.h> inline void func(char *s) { // Each of these will print a different address for s // if the arg was a string literal. cout << "address of " << s << " is " << (int) s << endl; cout << "address of " << s << " is " << (int) s << endl; cout << "address of " << s << " is " << (int) s << endl; // This will print a negative number if the arg is a literal. cout << "the difference between (s+1) and s is " << ( (s+1) - s) << endl; } int main(int argc, char *argv[]) { func("hello"); char *bye = "goodbye"; func(bye); return 0; } Here is a demo program that shows how this impacts STL: #include <iostream.h> #include <string> string str("hello"); int main(int argc, char *argv[]) { cout << str << endl; return 0; } This will print "hellohello" on a broken compiler version. The fix for this is to add this line to the beginning of func(): s = s; This somehow makes the compiler stop creating new copies of the string, and if you compile with -O, it seems to completely optimize away, so there is no runtime penalty. There is a substantial ugliness penalty, though, as this line has to be in every inline function that can be called with a string constant. The fix could be done with the preprocessor macro __SUN_INLINE_STRING_LITERAL_BUG, which should be empty on all platforms but SUNPRO version 4.2 or before (/fbp/this change is not in 3.12 yet, as I still hope to find less ugly solution, maybe with compiler flags /fbp/): #define __SUN_INLINE_STRING_LITERAL_BUG(x) x=x; (for Sun CC) #define __SUN_INLINE_STRING_LITERAL_BUG(x) ( for other compilers) . You should be careful passing string literals with SunPro CC (frankly - NEVER do that), as the above bug appear in any inline function (not only template ones). #### Compiling If your program is multi-threaded, make sure you defined macro `_REENTRANT` to enable proper synchronization . That will enable use of Solaris threads synchronization support. If you are usizg Pthreads in your program, define _PTHREADS for STLport. If your project has multiple directories structure, it is better to use -ptr option to keep all template databese in one place. ## Note for SUNPro C++ 4.1 users ## Known problems #### Compiling C++ 4.1 have problems recognizing types nested in template classes when parsing declarations. For example , the following construct fails (suppose STL vector is a base type for derived_vector ): `derived_vector<int> years;` `derived_vector<int>::iterator i;` To work around this problem completely, you should repeat those typedefs from base class that you are going to use in any way: `template <class T> class derived_vector : public vector<T> {` `typedef vector<T>::iterator iterator;` `...` STL code itself is now free of this problem. C++ 4.1 may also suffer from optimization bugs when using exception handling. If your application doesn't use exceptions, you'd better use `-noex` option along with `__STL_NO_EXCEPTIONS` flag. #### Linking You may have troubles getting linker errors compiling multiple targets in one directory ( for example, running cygnus testsuite). That is a bug in handling Templates.DB dependencies. Known solutions are : a) for one-file tests, specify option -pto (one-file-mode) option to turn off database completely. Option -pts(single-file-mode) doesn't fix all problems. b) for complex projects, use separate Templates.DB directories for different targets. ## Notes for SUNPro C++ 4.0.1 users ## Known problems #### Version problems If your CC 4.0.1 cannot compile testsuite, most likely you are using out-of date version. You should download patches for 4.0.1 (SparcCompilers WorkShop 3.0.1) from SunPro site : Solaris 2.x : http://www.sun.com/workshop/tnb/sparc2x/patch.html (SPARC/Solaris 2.x) . You should look for patches 101242-12 & 101242-14 ( 101242-12 is required to work with 101242-12). Sunos 4.1.x: http://www.sun.com/smcc/solaris-migration/cmc.products.970709/XCM/101914-14.tar.Z (SPARC/SunOS 4.1.x) http://www.sun.com/workshop/tnb/sparc1x/patch.html (SPARC/SunOS 4.1.x). Look for 101914-20. #### Compiling C++ 4.0.1 have problems recognizing types nested in template classes when parsing declarations. For example , the following construct fails (suppose STL vector is a base type for derived_vector ): `derived_vector<int> years;` `derived_vector<int>::iterator i;` To work around this problem completely, you should repeat those typedefs from base class that you are going to use in any way: `template <class T> class derived_vector : public vector<T> {` `typedef vector<T>::iterator iterator;` `...` More severe problems arise when given template argument's typedefs are used as template arguments for base class. The example is function adaptors from function.h . Refer to workarounds for binders & composers to see how it can be hanled ( proposed by "Martin Abernethy" <gma@paston.co.uk> ). C++ 4.01 may also suffer from optimization bugs when using exception handling. If your application doesn't use exceptions, you'd better use `-noex` option along with `__STL_NO_EXCEPTIONS` flag. #### Linking You may still have to use explicit instantiations and/or specific template database controls for complex cases to avoid "unresolved symbol" linker errors. You may have troubles getting linker errors compiling multiple targets in one directory ( for example, running cygnus testsuite). That is a bug in handling Templates.DB dependencies. Known solutions are : a) for one-file tests, specify option -pto (one-file-mode) option to turn off database completely. Option -pts(single-file-mode) doesn't fix all problems. b) for complex projects, use separate Templates.DB directories for different targets. ## Migration notes You should experience no other problems migrating from HP STL to SGI STL. #### Versions prior to 4.1 For info on SUNPro C++ 4.0.1, see README.sunpro401. SUNPro C++ older than 4.0.1 won't compile STL. You have to upgrade.