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. > 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. > *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. The library incompatibility constraints have been clearly defined in the existing ARC Case. C++ Language ABI considerations are beyond the scope of this Case. 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. 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. 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. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
