Re: [boost] Boost libraries after C++0x acceptance

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