Boost logo

Boost :

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
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
main obstacle to more libraries and I don't think the idea of standard
addresses this problem.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at