Edward Diener wrote:
Robert Ramey wrote:
The idea that making a library interface "standard" confers a sort of legitimacy that says: "a library that implements this interface would be a good (or necessary) thing to have" has some validity. But having a commitee say it has to have this thing to be considered a comforming implementation seems to be superfluous given the presumption of conforming language translator and reference implementation which conforms to legal C++.
I think you are arguing from an emotional perspective which feels that there is no necessity to have standard libraries as long as libraries are implemented in a C++ standard conforming way. The minimalist approach feels good to you.
Well, I plead guilty to the preference for minimalism. But DAMN IT - I'm NOT emotional about it. I don't think that the idea of the standard library is detramental - In fact I've conceded the point that the fact it has the "official sanction" is helpful in a number of organizations. But I just don't think its really very effective in achieving what I think is the goal - making C++ more widely useful. Also I think it creates the impression that efforts underway to make C++ more widely useful than I think they could be.
It is a nice ideal but in practical use fails because of the reality of compiler conformance. I too would love to have all compilers 100% conformant to the C++ standard. In an ideal world this would be so, and therefore a library which is 100% conformant would automatically work with any library which was 100% conformant, and therefore specifying a standard library would be a moot point, as long as there were a single conforming library which one could use.
This is more or less my line of reasoning.
Unfortunately that world does not even approximately exist in C++, and to think it does, and therefore there is no need to have a C++ standard library, as opposed to 100% conformant C++ libraries, such as a 100% conformant reference implementation of the current C++ standard library, or of 100% conformant third party libraries like Boost, is just wishful thinking.
Ahhh - and why is that? why is it so hard to have a 100% conformant compiler that no one has been able to it. That is another question we should be asking ourselves. As you note - this is the key source of the difficulty. And its even worse. Given two 100% conforming compilers, there are areas in the language which are undefined and left to the implementors. Many of these don't effect language semantics - but some do. So even with two 100% conformant compilers there is not guarentee that the same library can be compiled on both with the same results. And that's a problem. Having each vendor tweak his library around this is A solution. But not a very satisfactory one as far as I'm concerned. Hmmm, so, maybe I've answered my own original question here. 100 % comformant compilers cannot be guarenteed to be equivalent - so a vendor MUST include implementation of a standard library which he has verified will work on his compiler. Of course I'm not really happy with that answer - it doesn't help me guarentee portability of my own libraries as I would like - but it IS an answer and probably the "real" one. Oh Well.
I want to also point out to you that even implementations which are, supposedly, 100% conformant to the particular language, such as Sun's Java JRE or Microsoft's .NET implementation, ship automatically with a set of libraries which may be called the standard library for that "language". Do you think that they should not, but rather say that there is a bunch of libraries out here somewhere, presumably on the Internet,
I have no issue with a bunch of libraries being shipped with a compiler. It's very convenient to have pre-build libraries. I use MFC this way all the time. God help me if I had to build it. But my question is "what is thebenefit of having a ""standard library" defined when there is a free working implementation. After - the free working implementation IS a definition of the API. Robert Ramey