Garrett D'Amore wrote: > So the questions/concerns I have about this are: > > 1) Is there any long term plan for rectifying the differences between > Studio-supplied Standard C++ libraries and this version?
These differences cannot be rectified, due to the backwards API compatibility constraints of the existing libCstd.so.1. In other words, the existing libCstd.so.1 is frozen in time. It is currently not Standard C++ Compliant, and has been so for 10 years. This means: any Sun customer developing Standard Compliant C++ software (meaning: wanting to use Standard Language features unavailable in libCstd.so.1) will either: 1. Not use Sun Studio. 2. Not use Solaris. > 2) It seems like we (Sun and OpenSolaris both) ought to be putting our > weight behind *one* of the implementations. As explained above, we cannot do that, unless we want to remain Standard C++ non-compliant forever. > If the Apache version is the best version (I gather that the Studio supplied > libraries are > somehow deficient, but I don't understand why), libCstd.so.l must maintain compatibility with Sun Workshop 5. At the time Workshop 5 was released, the compiler did not implement all the language features mandated by the Standard. The deficiencies were primarily in the compiler support for Partial Template Specializations, std::iterator_traits, etc. Introducing support for these mandatory language features in the current libCstd.so.1 would break compatibility with the existing libCstd.so.1 (for example, because the sizes of some of the existing classes and structs in the Standard C++ Library and STL will change). > then perhaps its time we > take a look at a general move to mark the Sun stuff Obsolete, and direct > users towards the newer version. > > 3) Given the rotten ABI incompatibilities that exist already in C++, one > could argue that precedent has been set. Indeed it has. > However, I feel that making > this problem worse by adding yet another system-supplied > and-incompatible C++ library is asking for severe trouble. Without some > long term plan to consolidate on (and recommend) a single ABI, > developers are left confused as to which they should be using. There appears to be confusion here between the Sun C++ ABI, and the library incompatibility between the existing libCstd.so.1 and the Apache Standard C++ Library. The Sun C++ ABI does not change with the introduction of the Apache library. Actually, the Apache library links against the existing libCrun.so.1, and will conform to the Sun C++ ABI. It is the Library ABI's that are incompatible. C++ developers are well aware of incompatibilities between different implementations of the Standard C++ Library. These incompatibilities exist regardless of the compiler ABI in use. The GNU Standard C++ Library is not compatible with the Apache Standard C++ Library, either, even in the case where both were compiled with the exact same compiler. This library compatibility conflict currently exists today, in Solaris, with the presence of the STLport implementation of the Standard C++ Library. However, the Apache implementation of the Standard C++ Library is far superior to STLport (if for no other reason other than full internationalization support in Apache, which is absent in STLport). And even if it wasn't superior, STLport is still incompatible with libCstd.so.1 as well. > 4) If you have an application that needs to bring in libraries from > multiple sources, each of which were built against different C++ > standard libraries, you wind up with a situation where the binary can't > work. And, its not clear to me that the poor developer stuck here > trying to use one set of libraries linked against Apache's code, and > another against Studio's, has a way to know that a problem is lurking, > much less a way to avoid or solve it. Standards Compliance trumps potential (although not really possible) developer confusion. > 5) Yes, I know that this problem already exists with Gnu C++ versus > Studio compiler ABI incompatibilities. However, I'm strongly opposed > seeing this problem increased by another degree of freedom if we can > avoid it. This is not a degree or measure of freedom, this is a matter of becoming compliant with an Industry Standard which was adopted 10 years ago, and which is supported by all our competitors (I am deliberately not including GCC in this statement, since GCC does not observe the same compatibility constraints to the same degree to which the IBM, HP and Microsoft compilers do). This lack of compliance prevents us from introducing other C++ components (read: BOOST) which are currently widely used in the industry, and by our customers. > 6) The failure mode if mislinked programs (random application > misbehavior) makes me very unhappy. I'd far rather have a failure occur > at compile or at least at link time. And that is exactly where the vast majority errors will occur. The case of "random application misbehavior" simply does not exist when linking against conflicting Standard C++ Libraries. The application simply crashes on startup, if it manages to link, and if the link editor did not already cause fatal errors because of either undefined or multiply-defined symbols. > I consider these compatibility concerns rather grave. Any C++ software developers worth their title knows that "Thou Shalt Not Mix Different Implementations Of The Standard C++ Library." This is not a language bug, it is a language feature. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
