On Tue, Nov 22, 2011 at 12:02 PM, Robert Ramey <ramey@rrsd.com> wrote: ...>
But that's all really aside from my main concern. I'm really thinking of something quite different. My understanding is that the the C++ commitee defines the requirements that a C++ compiler must fulfill to be considered "conforming". On the face of it I would interprete this to mean that a compiler is "conforming" if it can parse text written in accordance with the standard and produce an executable which will produce the expected results.
The standard actually "states only requirements on C++ implementations". It talks throughout the standard about "conforming implementations". The term "conforming compiler" never appears in normative text, and only appears once in a non-normative footnote.
But some time ago, it seems that "conforming compiler" morphed into "conforming C++ developement system" where by a compiler isn't considered "conforming" unless it's delivered along with an implementation of the standard library.
That's not correct. Since at least 1993 when I joined the committee, the focus has always been on "conforming implementations" rather than conforming compilers. The library has always been part of that. And before C++, the C standard also talked about conforming implementations rather than compilers, and the C library was also part of that definition of conforming.
This raises a number of questions to me:
a) if some company were to produce C++ compiler does he also have to produce a standard library implementation? If he does - that would be a huge barrier to entry for anyone wanting to make a new compiler.
Both C and C++ standards avoid any discussion of where a conforming implementation gets its various bits and pieces. That's considered beyond the scope of the standard.
b) if somes delivers a compiler with out a standard library is this compiler considerd "non-conforming".
The implementation is never conforming if it doesn't conform to the library clauses. Likewise, a library is never considered conforming unless the whole implementation is conforming.
c) can someone just attach a copy of boost and/or stllib and still call his compiler "conforming to the C++ standard"?
Boost isn't conforming for any number of reasons, starting with the namespace:-) And while the marketing departments of some compiler suppliers claim all sort of outrageous things, don't believe them any more that you might believe the marketing folks at your local used car dealer:-) Seriously, some compiler suppliers do offer choices of several standard libraries. That's simply beyond the scope of the standard, so the standard folks don't care.
d) doesn't adding libraries to the standard make it more difficult and expensive to produce and sell a "conforming" C++ compiler.
Yes, for a "conforming implementation".
Is this a good thing. Wouldn't adding hard to implement libraries like fusion make this problem (if it is a problem) worse?
Library suppliers participate in the committee's LWG, and will let the committee know if they think cost of supplying a particular component creates a problem. That's what happened with the TR1 math special functions, so they did not go in C++11, but instead were given their own TR.
e) I question the priorities of the standards committee. I see lambdas as interesting, but really I can't imagine any of the customers I deal with every using them. (get other customers? - right). and this has to add complexity the the process of making a new C++ compiler. And a lot of commitee effort is spent on this. Meanwhile somethings create problems like issues raised by run time linking - (ODR violations, visibility, etc.) seem to get less attention - even though I would think they would be easier to address. Of course this is just me speaking as a lowly application developer.
The standards committee is just like Boost - a volunteer effort. So if no one volunteers for something, it doesn't happen. Conversely, if a really difficult area draws a lot of volunteers, it happens even while some simple things languish for lack of volunteers. --Beman