Edward Diener wrote:
Robert Ramey wrote:
Edward Diener wrote:
Is that your argument ?
My argument is really a question:
Given a library for which there exists a free reference implmentation in terms of legal C++ language syntax, what value is gained by adding it to some standard?
It ships with a C++ implementation which correctly works with it
That cannot be guarenteed by a standard. and
all C++ programmers know that if they use that library in their code it must work correctly on any other conforming implementation.
Also cannot be guarenteed by the standard.
I think you are greatly underrating the ability of a C++ programmer moving from one C++ implementation to another, as I have from C++ Builder to VC++ in personal projects on which I am working, and knowing that the standard library usage in the code is guaranteed to work on both.
Actually, my thinking on this was much influenced by the efforts required to make the serialization library portable accross a good array of platforms. This is a huge effort and adds a lot to the effort required to make something like the serialization library (or I'm sure regex) widely compilable and runable. The "standard library requirement" doesn't help with this. I think that one reason that other languages have been gaining popularity is that much less effort (if any) is required to port libraries. If the C++ community want's more libraries, making more "standard librarie requirements" won't help. What's needed is refinements in corners of the language which inhibit portability.
Now let's assume there is no standard library. Then as a C++ programmers switches from one implementation to another, there is no guarantee that the code will compile on any given implementation.
My argument is applied to libraries which are free, available and conformant with the C++ language. If this doesn't guarentee that they will compile on any conformant implementation - then there is something wrong in the language specification. If this is fixed then one won't need the standard library.
Taking 3rd party libraries, with Boost as the example, as good as it is if a compiler vendor does not support a Boost library because that compiler vendor has bugs in their [compiler A] implementation or does not support a C++ standard language feature which the particular library uses, then an attempt to compile code when going from a compiler vendor [compiler B] which does support a 3rd party library to one that does not support a 3rd party [compiler A] library will fail.
Ahhh - there's the rub. But what's causing this? In our scenario. Regex is presumed to be conformant with the C++ language. So if it doesn't compile on compiler A - A can't be a conformant compiler. So even if the vendors of compiler A includes some working standard library implementation, it's STILL non-conformant because it can't compile the code in Regex. Once a compiler is non-conformant - working around its quirks to make it compiler and run all the functions in the standard library doesn't make it conformant - that bell was already rung. The existence of the the standard library has helped motivate the vendor to work around the problem - rather than fix it. On the other hand, a conformant compiler doesn't need the standard for those libraries which have a free, available implementation written in C++ - they are by definition going to work.
Now let's suppose that 3rd party library is added as a C++ standard library. Immediately the compiler vendor which has the bugs or does not support a C++ standard language feature needed by that library, and wants to be compliant to the C++ standard library, needs to fix their problem. This to me is a good thing.
He can fix his implementation of the standard library. But it won't make his compiler conformant to the C++ language. This is a pity. Robert Ramey