Joerg Barfurth wrote: > Hi, > > What I'm going to say really just reiterates the need to coordinate with > the compiler group (with which I am not particularly affiliated). But I > think I have some more arguments.
> If they don't need ABI compatibility on Solaris, there are existing > alternative, in particular use of the STLport shipped with SunStudio. So, this is the argument for being out of sync and non-compliant with a 10 years old Industry Standard ? "If you don't like that we're not Standard Compliant, go elsewhere" ? Sad to say, many customers have already done that -- they went elsewhere. I didn't realize that chasing customers and developers away was a strategic direction at Sun. But maybe i'm misinformed. >>> 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. >> > > Other have already made a strong case that this should be coordinated > with the compiler folks. At least there should be agreement whether > STLport or stdcxx is the best way forwards. The purpose of this Case is not to engage in a religious debate as to which of the two (STLport or stdcxx) libraries are better. I've already explained the inherent weaknesses of STLport, and the advantages of Apache. By sumbitting an ARC Case for Apache, and not STLport, the Case already implicilty asserts that Apache is better than STLport. This argument seems to be supported by usage in the industry. The Apache library is really nothing more than the RogueWave Standard C++ Library. Interesting that full internationalization and localization support, which is a *requirement* for integrating software in Solaris, is presented here as a weakness or defect. In light of this unusual line of argumentation, may i ask: has the requirement for internationalization and localization support in Solaris been dropped, and the strategic direction changed, to not support these facilities ? > BTW, I see that you suggest giving this library a Committed stability > classification. This may lead you into the same corner where libCstd > currently is caught: > > - Experience (e.g. the multitude of 'final stable ABI' releases of g++ > and its library) shows that it is very difficult to determine that > something is perfect enough that future bug fixes won't require more ABI > changes. The GNU C++ Compiler is known to break C++ ABI between minor or even micro releases. This case does not propose building the library with the GNU compiler, and does not address the weaknesses of the GNU compiler. Comparisons between the GNU compiler and the Sun Studio compiler are not germane to, or in scope for, this case. Many other compilers have many other different problems, none of which are being addressed in this Case. > - There will be TR2 and eventually the next version of the Standard. > Being 'Committed' may make the hurdle to accomodate these revisions very > high. Yes, the Library ABI will break again when the new Standard is adopted. This will require a new Library. This is a known fact, right now, and this is precisely the reason why the directory layout structure for Apache is organized the way it is: /usr/include/stdcxx. When the new Standard is implemented in a new library, it will maybe go into /usr/include/stdcxx0x, and the library names, and the binding SONAME will be different. This Case does not attempt to address "what might happen in the future". This Case is about the integration of a Fully Standard Compliant Standard C++ Library. Insofar as the future direction of the Standard C++ Library is concerned, in an as-of-yet unapproved ISO Standard, this Case cannot address the non existing standard. The C++ Standard implemented by this library is ISO/IEC:14882:2003. That Standard has been approved. > - You can maintain ABI compatibility only as long as the compiler does. > If you commit to an ABI now, you may be stuck with being tied to a > -compat switch and can't benefit from compiler improvements, if the > compiler group eventually makes the step to a 'major release' (i.e. a > new compiler ABI). This argument is equally valid for the Standard C Library, or, for that matter, for any other compiler/compiled language combo. "You can maintain ABI compatibility only as long as the compiler does". True. If the Sun C Compiler decides to break the C ABI, the Standard C Library will break. The same statement is equally true for Fortran. How is this relevant, or particular, to C++, and the Standard C++ Library being proposed in this ARC Case ? The "Committed" Interface Stability classification level, assigned to this library, implies, or states, _nothing_ about the *compiler's* C++ ABI Stability Level, given that the library does not control the compiler's ABI stability level. If the compiler breaks the C++ ABI, then all the libraries built with said compiler will break, including existing "Committed" ones. This hypothetical breakage is beyond this Case's scope, or control. This Case is *not* about the Sun C++ ABI. > Yes, but this is a PITA. Having a reasonably stable C++ ABI is a > precondition for being able to ship binary applications that support > plugins or binary plugins for existing applications. Again, the Sun C++ Compiler's C++ ABI is not being addressed in this Case. Again, there appears to be confusion between the compiler's C++ ABI and one library, or another's ABI. Compiler C++ ABI != Library ABI. This Case assigns "Committed" to the interfaces of the Standard C++ Library because: [1] the library implements an Industry Standard and [2] the interfaces are not expected to change in an imcompatible way, given that these interfaces have been defined in a Standard. For all we care, this Library can stay as is for the remainder of time. > This is already pretty messy in cases like Mozilla or OpenOffice.org, > which both support extensions through a component model with a native > C++ binding. > > So by all means let's try to make a new, hopefully longer-lasting, > stable C++ ABI. But that only works if the compiler and library take > that step together. > >> 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. >> > > But then why is having three incompatible libraries better than two? > > STLport already supports the most important points of what you are > setting out to do: > - It is vastly more standards compliant than libCstd (at the cost of > being incompatible). > - It supports use of most of Boost. Again: STLport is first of all: obsolete, only supports the "C" locale, and it has significantly less industry traction than Apache/RogueWave. Also, this case does not propose the integration of a "vastly more standards compliant" library, since the definition of "vastly more standards compliant" is in the eye of the beholder. This case proposes the integration of a Fully Standard Compliant library. This is a very significant difference. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
