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