John Plocher wrote: > Stefan Teleman wrote: >> Or, how is this same proposal consistent with the Principle Of Least >> Astonishment ? > > > 1) What happens TODAY when I have > > A) A middleware C++ module that uses the STLPort4 Standard C++ Library > B) A different middleware module that uses the Apache Standard C++ > Library > and > C) A program that needs to use both middleware libraries? > > (I would expect pain and suffering and a failed build, but I could be > wrong.)
Does not work, cannot work, instant breakage. > > 2) Is the answer different if you postulate having the sources for A and > B -vs- > only having shared object libraries? Nope. > > 3) Are the various Standard C++ Libraries compatible at all at the > source level? Nope. > > and finally, > > 4) What is the big picture with respect to all these choices? Incompatibility between different implementations of different Standard C++ Library's is a known fact, it comes with the language. The big picture is: using the Apache Standard C++ Library is a voluntary choice, and it must be explicitly enabled (via specific compiler flags, in existence today). Using it will break any compatibility with libCstd.so.1. > What I'm hoping to hear for this last one is something like > > STLPort4 is old and obsolete, but kept around for customers who have > source and/or binary compatibility requirements with the [xxx] > Standard. True. > STLPort5 is a newer-but-source-and-binary incompatible replacement > for STLPort4 that is compliant with [xxx] Standard. True. > The Apache Standard C++ Library has the following relationships > to the above [...]. - Apache Standard C++ Library has no relation to STLport, either 4 or 5. - Apache Standard C++ Library is the RogueWave implementation of the Standard C++ Library. > New C++ code should be written to use [...pick one or more...] > because [... rationalizations...]. New C++ code which must make use of Standard Language facilities not supported in libCstd.so.1, should use the Standard Compliant C++ Library (Apache) -- being proposed here, for the following reasons: - Fully Compliant with the 1998/2003 C++ Standard - Full Internationalization and Localization support (absent in STLport4) - Thread-safe - 64-bit clean However: mixing any two different implementations of the Standard C++ Library in the same address space does not work. > New C++ middleware libraries should/must use [... pick one...] in > order to ensure that applications can actually be built that use > multiple C++ modules. Not possible. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
