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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-10-09 13:05:52

Ames Andreas wrote:
>> -----Original Message-----

> In an ideal world, I think, the answer would be none, no.  In practice
> things are different.
>
> 1)  From the user's perspective:  Very few people seem to choose
> languages because of syntactical purity (think Perl) or e.g. the power
> of control it provides to you (manual memory mangement, pointers
> etc.). The deciding factor often seems to be the availability of a
> standard lib (Java, .Net).  Most needed things are in place when the
> user installs a 'development environment', no need to search the web
> on and off, much better access to secondary literature (how many
> books are available about boost libs compared to books about the STL,
> Java SDK ...  One could
> ask now, why it is more rewarding to authors to write books about
> 'standard libs' than about 'free reference implementations').

I would make one small change to the above statement - removing the
word "standard" so tha tit reads

The deciding factor often seems to be the availability of a [standard] lib 
(Java, .Net).

I see very successful libraries - MFC - totally non portable that are
successful because they provide the right toolkit for the job.  The
fact that they are not standard hasn't been relevant.

> A standard lib might also offer some sort of protection from vendor
> specific derivations (esp. when there exists a monopoly) i.e. there is
> not yet something like a 'Microsoft C++'.

> 4)  From a quality perspective:  I hope that the standard lib is
> reviewed by a much broader audience than boost.  For example compiler
> vendors may have a vital interest in participating in the former
> process.  This could lead to different assessments of a lib's
> interface (e.g. it might not be efficiently implementable).

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

As long as a library implements the standard, quality is beyond
the perview of the standard.  Issus like efficiency, sideeffects,
etc are not addressed by the standard.

> This is comparable to other fields:  Why is there something like
> POSIX, if we have Linux?

This is a totally different situation and I believe that modeling C++
libraries on this situtation is what has lead to what I see as a mis-guided
use of resources.

POSIX defines an API which a *nix system has to implement in order
to be "posix compliant".  Its basically a wrapper around each different OS
which are all different.

But C++ library is really a wrapper around standard conforming C++ code
which is basically all the same.

So the argument I'm making can't be applied to POSIX/BSD/Linux, etc.

It seems to me that a common thread is

a) C++ needs more libraries to remain competitive with other languages like 
Java
b) Adding more libraries to the standard will help achieve this.

I'm questioning b)

I see the difficulties of porting C++ code among implementations as being 
the
main obstacle to more libraries and I don't think the idea of standard 
libraries
addresses this problem.

Robert Ramey