Boost logo

Boost :

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
>> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk