From: Robert Ramey (ramey_at_[hidden])
Date: 2006-10-08 18:52:28
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
> It ships with a C++ implementation which correctly works with it
That cannot be guarenteed by a standard.
> C++ programmers know that if they use that library in their code it
> 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
> that the standard library usage in the code is guaranteed to work on
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk