Common Notes

Notes for SUNPro C++ users

Known problems

Compiling

Known problems

Bugs (Note for SUNPro C++ 4.2 or before)

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

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

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

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

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 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

Versions prior to 4.1