Classic/Standard iostream question ?

Question

Hi,
I was experiencing a problem with one of our libraries lately due to the fact that a customer of ours was getting undefined symbols like the following when linking against our library and stlport4 library:
std::ostream &std::ostream::operator<<(short)
std::ostream &std::ostream::operator<<(int) etc
__rwstd::rwse_eofbit_set
[Hint: static member __rwstd::rwse_eofbit_set must be defined in the program] Now I believe the reason as to why this is happening is because our library is exposing symbols which it expects libCstd to resolve when linking but because stlport4 is being used; these symbols are not resolved.
Now we are supposed to be classic iostream compatible but I noticed by using the command dump -C library that there where many references to the std namespace (std::) in the symbol table outputted.
We build on solaris 2.7 using FORTE 60 and also on solaris 2.8 using FORTE_61 and our build line was pretty standard (i.e. we used CC -c and some includes and by default accepted compat=5 libs).
Now I have rebuilt our libraries so that all references to std:: in the symbol table are now gone. To do this i used the following C++ flags:
-compat=5 -library=iostream -library=Crun -library=no%CstdI have a few questions ?
Is the build/link flags above correct to be classic iostream compliant ?
What is sun's stand on mixing classic and standard iostreams in particular how does one use the STL library in classic mode ?
Finally - if i release the product library using classic iostream - can a customer safely link against our product library and the default compat=5 (i.e. libCstd, libCrun and STL etc) ?
Any help or pointers much appreciated ?
Cheers,
Clive

Answer 1

To use classic iostreams and to be sure you are not using libCstd, use the option
-library=iostream,no%Cstd
on every CC command line, compiling and linking.
The C++ Migration Guide says that you cannot mix classic iostreams and standard iostreams in the same program. Actually you can, and I'm having the document updated. But the requirements are fairly strict. But classic iostreams have been obsolete since 1998, and can be used only with extreme care in conjunciton with the standard library. I think you would be well advised not to use classic iostreams in modern C++ code.
In any event, here are the restrictions on mixing iostream versions:
1. Do not mix versions on the same stream (fstream, strstream, etc).
2. For the standard streams (cin, cout, cerr, clog), use one version consistently throughout the program. Since cin and cout are tied, reading cin using one version writing to cout using another version can cause strange program behavior.
3. Do not include classic iostream headers in a module where you include headers from the C++ Standard Library. The standard library depends for correct operation on using standard iostreams, and you could wind up trying to apply classic iostreams to standard library objects.
The likely scenario for mixing iostream versions arises from using libraries from different sources that you don't control.
Let's suppose the main program uses the standard library, and you want to link a library L that uses classic iostreams. The library should not use the standard streams (cin, cout, err, clog), should not use the C++ Standard Library, and it should communicate with the program via an interface that does not involve iostreams. That is, the main program should be able to use the library without including any classic iostream headers.
Build library L as a shared library with a dependency on ibiostream:
CC *.cc -c -Kpic -library=no%Cstd,iostream
CC -G -o L.so *.o -library=iostream,no%Cstd,Crun -lc
Build the main program without reference to libiostream, and link it to L.so.
If you use this kind of separation, you should not have any problems. If you have more mixing of streams or mixing of classic iostreams with the C++ standard library, you may run into problems. The issues are not details of the C++ implementation, but are fundamental to the design of iostreams and the C++ standard library.