PSARC/2008/549 - Apache Standard C++ Library

[Garrett D'Amore]

Stefan Teleman wrote:
>
>
> Garrett D'Amore wrote:
>
>> Then perhaps each of them winds up with their own project private 
>> copies.  Or perhaps one of them gets a contract from the other.  I 
>> don't know what the best solution involving non-public binding is.  
>> Clearly, a Public Committed API is better.  I just don't think a 
>> Public Committed API and (more importantly) ABI can be arrived at in 
>> the scope of a fast track.
>>>
>>> That would defeat the purpose of the integration in the first place.
>>>
>>> You are essentially saying:
>>>
>>> 1. We are introducing a Standard compliant library which was not 
>>> present before.
>>> 2. You [ Solaris Developer | Sun Customer ] have been waiting for 
>>> this library for 10 years.
>>> 3. This library tracks the 2003 C++ Standard.
>>> 4. You [ Solaris Developer | Sun Customer ] cannot use this library.
>>
>> I'm saying that this is true *unless* you're willing to step up to 
>> the plate to provide the guarantees that would be required, and that 
>> I think it would require a full case review in order to fully assess 
>> that.
>
> Which guarantees ?
>
> The library guarantees ABI stability within Major Release 4 
> boundaries. It also implements an Industry Standard. As such, it is 
> suitable for a Committed classification. However, you oppose this 
> stability classification. This is one example of a guarantee provided 
> by this library, which you oppose.
>
> Where are the specifications for these other guarantees that you are 
> seeking ? Where have these constraints -- controlling these 
> unspecified guarantees -- been defined ?
>
> You are opposing the guarantees explicitly provided by the library, 
> and instead, you seek an unspecified set of other guarantees, for 
> which you have not provided constraint definitions.
>
> This fast-track cannot address architectural requirements constraints 
> which are:
>
> 1. Outside the scope of the case itself.
> 2. Intangible and/or impossible to define (example: ävoid developer 
> confusion).
> 3. Based on the introduction of continuously changing requirements, or 
> definitions.

Okay, we have a significant failure to communicate.

First off, *SOURCE* level commitment is *NOT* the same as binary 
commitment.  The Standard says *nothing* about binary commitment.   I 
understand that the project seeks to provide a conforming implementation 
of the Standard -- that says *nothing* about compatibility of 
applications or libraries provided here.

All those other "constraints" are certainly *in scope* if you seek to 
create a new binary ABI for C++ programs.  If you're talking about a new 
stable base library (instead of the shipping libC) then this is what 
you're doing.

Let's be 100% clear here:

There are exactly three ways forward for the project team (short of 
trying to do something to get me ejected from PSARC):

1) reduce the scope of what you're supplying to Project or Consolidation 
Private

or

2) have your case derailed (voluntarily or otherwise) into a full case, 
and deal with the full consequences of creating a new C++ ABI for Solaris

or

3) withdraw your case altogether.

My personal preference at this point is #2.  Unless you state your 
intention to follow course 1 or course 3, please consider your case 
derailed.  I'm willing to talk off line with you and the compiler folks 
to help formulate appropriate materials for a full case.

    -- Garrett

(I have other responses inline below, but they may or may not be 
worthwhile.)
>
>> I'm *not* saying we can't or shouldn't ship this.  I'm saying that we 
>> shouldn't do the job improperly.
>>
>> PLEASE, don't make the mistake of believing that that derail == deny.
>> All derail means is that the project falls outside of the scope of 
>> "obviousness" that makes it appropriate for a fast track.  The large 
>> amount of discussion we've already had around this project (and 
>> continued levels of "discovery" surrounding the case) strongly 
>> represent to me that this case is *not* obvious, and should not be a 
>> fast track.
>
> The large amount of discussion generated by this case has discovered 
> nothing that was not already specified in the ARC Case.

Not true.  The details of the i18n were not specified originally.  The 
plans of the compiler group were not specified. The interaction with g++ 
was not well specified (nor the fact that g++ support isn't needed.)  
And, the discovery (at least on my part) of prior case work specifying 
that we actually already have a C++ ABI that this project would be 
breaking, may not be new information, but it was new *to me*, and 
certainly wasn't spelled out in the materials.

>
>> *However*, if you're only worried about one or two consumers, and are 
>> willing to have a greatly reduced commitment, then I'm willing to 
>> stand aside and let it go as a fast track.
>>
>> But lets not pretend that you can create a new C++ ABI (and thats 
>> what this case as proposed would do!) without properly addressing the 
>> compatibility considerations and without a regular and complete review.
>
> This is a very good example of constantly changing constraint 
> requirements, and definitions. Nowhere has this cased proposed the 
> creation of a new C++ ABI. Extending the scope of this Case from 
> clearly defined library ABI incompatibilities, to C++ Language ABI 
> compatibility considerations, is a stretch, and it is not supported by 
> the facts.

If you're going to create a Committed C++ library that is incompatible 
with libC, then by *definition* you are creating a new C++ ABI.  Even 
though you didn't say this was your intent, it is the natural effect of 
what you're proposing to deliver.

>
> The library incompatibility constraints have been clearly defined in 
> the existing ARC Case. C++ Language ABI considerations are beyond the 
> scope of this Case.

We seem to be talking across each other.  The ABI derives from the 
*combination* of the compiler used *AND* the base library (or libraries) 
used.  By introducing a new base library, you are creating a new ABI.

>
> It is already known that the next iteration of the C++ Standard will 
> break the existing Compiler ABI, and the library ABI. As such, any 
> considerations of library ABI incompatibility concerning this ARC Case 
> are irrelevant for the next iteration of the library, or for the next 
> Language implementation itself.

Yes, we don't know what the next iteration of the language, or possibly 
the library, will do.  But our customers *insist* on a stable foundation 
that doesn't change underneath them.  This means that we have to provide 
some reasonable guarantees that the parts will fit together.

You can't slide by on saying "the future changes to the language may 
break future compatibility"... the precedents already set by the libC 
integration and C++ ABI cases are against you here.

>
> This library's ABI is incompatible with another two, existing, library 
> ABI's. The three libraries are not equivalent, they do not provide the 
> same facilities, they are not interchangeable, and they are mutually 
> exclusive. Accidental inclusion of the new C++ library is not 
> possible: the new library must be explicitly enabled, and the existing 
> default library must be explicitly disabled in the compiler. 
> Accidental inclusion of the new library's header files is not 
> possible: the header files are not present in the default compiler 
> search path.

There are serious problems with the incompatibilities though -- how does 
a developer know which library should be used?  So far we have had 
exactly *one* recommendation (one allowed library) for developers to 
build upon.  Other choices were verboten because of binary 
incompatibilities (though individual applications were and remain free 
to choose an alternate C++ base library, such use has many caveats and 
effectively prevents granting any kind of Committed binding to C++ 
libraries *other* than those built upon libC.

>
> The Standard C++ Language does not require the inclusion, or linkage, 
> of, the Standard C++ Library, in a program, or library. For example, 
> the libGLU.so (component of OpenGL, currently present in Solaris) is 
> written in C++, and does not use, or link against, the Standard C++ 
> Library at all.

And that isn't a problem.  This fact is totally orthogonal to your case 
or and my concerns.

    -- Garrett