STLport: Notes for SUNPro C++ Users

| Notes for SUNPro C++ Users ## Common Notes For all SUN compilers, STLport nables 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 _STLP_LINK_TIME_INSTANTIATION switch. Installation: please note that even if you do not use STLport iostreams, you still have to go to "src" subdirectory and do "make" or at least "make prepare" to produce additional .SUNWCCh files necessary for compilation) ## Notes for SUNPro C++ users ## Known problems #### Compiling ## Known problems #### Bugs (Note for SUNPro C++ 4.2 or before) Note: 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 `_STLP_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 `_STLP_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.
| Table of Contents
| Copyright 2001 by STLport