You can use the STLport implementation of the standard library if you wish to use an alternative standard library to libCstd. You can issue the following compiler option to turn off libCstd and use the STLport library instead:
-library=stlport4
See –library=l[,l...] for more information.
This release includes both a static archive called libstlport.a and a dynamic library called libstlport.so.
Consider the following information before deciding to use the STLport implementation:
STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport.
The stlport4 and iostream libraries provide their own implementation of I/O streams. Specifying more than one of these with the -library option can result in undefined program behavior.
Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version.
Tools.h++ is not supported with STLport.
STLport does not provide support for locales, which are used for internationalization and localization of text I/O.
STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4.
If you decide to use the STLport implementation, be certain to include header files that your code implicitly references. The standard headers are allowed, but not required, to include one another as part of the implementation. STLport tends to have fewer instances of headers including one another than other implementations.
The following test case does not compile with STLport because the code in the test case makes unportable assumptions about the library implementation. In particular, it assumes that either <vector> or <iostream> automatically include <iterator>, which is not a valid assumption.
#include <vector>
#include <iostream>
using namespace std;
int main ()
{
vector <int> v1 (10);
vector <int> v3 (v1.size());
for (int i = 0; i < v1.size (); i++)
{v1[i] = i; v3[i] = i;}
vector <int> v2(v1.size ());
copy_backward (v1.begin (), v1.end (), v2.end ());
ostream_iterator<int> iter (cout, " ");
copy (v2.begin (), v2.end (), iter);
cout << endl;
return 0;
}
To fix the problem, include <iterator> in the source.
See the Distribution README file for a list of libraries and object files that you can redistribute with your executables or libraries under the terms of the End User Object Code License. The C++ section of this README file lists which version of the STLport.so this release of the compiler supports. This README file can be found on the legal page for this release of Oracle Developer Studio software, at http://www.oracle.com/technetwork/server-storage/developerstudio/overview/index.htmlhttp://www.oracle.com/technetwork/server-storage/developerstudio/overview/index.html