Hi. My answers inline.
Paul Fee wrote: > Hello Stefan, > > I presume you've been working with Adriaan de Groot > http://people.fruitsalad.org/adridg/bobulate/index.php?url=archives/453-Oooh,-shiny!.html&serendipity[csuccess]=true#feedback Yes. > I'm migrating a Solaris project to SunStudio12 and shall be using > -library=stlport4 in order to use Boost 1.34. > > You mention that STLport4 included with SunStudio is open source and hence > doesn't provide > compatibility guarantees. The Sun Studio 12 documentation mentions that fact. In other words, linking against STLport4 creates a hard dependency on STLPort4. If the library changes in an incompatible way, you must re-compile and re-link all your applications. > Can you clarify how you see Apache/RogueWave STDCXX as being any different? It is different because we will compile our own STDCXX, which we will then use. We do not have to change or upgrade the private copy of STDCXX in a binary incompatible way. Also, i am aware that STDCXX tries to maintain binary compatibility at least between minor/micro releases. > Perhaps you feel that since you're using STDCXX manually and turning off > libCstd that you then have > more control and won't be stuck if SunStudio flags change in a future > release. After it's reasonable > to assume SunStudio won't drop the -library=no%Cstd flag. It is not the compiler flags which are the potential problem, it is the binary compatibility of the library which is the problem. Compiler flags changes are easy to handle in Makefiles -- worst case scenario is a simple sed script. But there are already two binary incompatible versions of STLport (4 and 5). > Can you confirm If it's concern over the volatile nature of -library=stlport4 > that has persuaded you > not to select this STL implementation? That is factor #1. Factor #2 was that is have used STDCXX for many years (the commercial RogueWave version), and i am familiar with the code. I've always found STDCXX reliable (although their insistent usage of implicitly typed unsigned is rather surprising). It survived some very hairy abuse of extremely large data sets, multiple threads and speed constraints. > You could still use STLport4 or Sr STLport5 by following the manual STL usage > proceedure (-library=no%Cstd). > In that case your choice of STL would be left to the merits of each > implementation. KDE is distributed as source. Anyone is free to use STLport4 or 5 instead of STDCXX when they build KDE. > I get the impression that Apache STDCXX is an evolution of libCstd, except > that Sun are compelled to compile > libCstd with limitations present in the earlier 5.x compiler series. This is > to maintain binary compatibility. > If Sun weren't tidied by this then I expect libCstd and STDCXX would be > equivalent. Sun libCstd is indeed based on an older version of RogueWave's STDCXX. It is not Standard compliant, because it has to stay backwards binary compatible with software written in the days of Sun Workshop 5. > Were there particular features of STDCXX that made it attractive? 1. Tried and true. 2. Localization/multibyte/nls support. 3. Personal hunch: Given that the current Sun libCstd is based on an older STDCXX, i would venture a wild guess and presume that a future, standard-compliant version of libCstd2 has greater chances of being based on STDCXX than on STLport. This is just my personal guess/hunch, i don't presume to speak for the Compiler Team. :-) BTW, BOOST 1.34.1 builds without problems with STDCXX 4.3.1 and Studio 12 fully patched, with one exception: on (64-bit) AMD64, $(TOPDIR)/util/collate.cpp in STDCXX, and ${BOOST}/libs/program_options/src/options_description.cpp cause an assert in ube. This only happens on 64-bit AMD. 64-bit SPARC is fine. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
