Re: [boost] Boost libraries after C++0x acceptance
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Sunday, October 08, 2006 11:35 PM Subject: Re: [boost] Boost libraries after C++0x acceptance
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?
If there value, is it worth the cost?
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'). 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++'. 2) For the lib developer(s): Being accepted into the standard lib flatters their vanity (no valuation intended here), may improve job offerings and other earnings etc. This could possibly be deduced from 1) above. 3) From the vendor's perspective: 1) and 2) seem to lead to economical and or marketing advantages when the vendor adheres to a 'standard', but I don't really know. 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). This is comparable to other fields: Why is there something like POSIX, if we have Linux? So in practice I'd say: If you care about the language you use, the answer might be 'a lot and yes'. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya DOT com
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
Robert Ramey wrote:
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++.
I think you are arguing from an emotional perspective which feels that there is no necessity to have standard libraries as long as libraries are implemented in a C++ standard conforming way. The minimalist approach feels good to you. It is a nice ideal but in practical use fails because of the reality of compiler conformance. I too would love to have all compilers 100% conformant to the C++ standard. In an ideal world this would be so, and therefore a library which is 100% conformant would automatically work with any library which was 100% conformant, and therefore specifying a standard library would be a moot point, as long as there were a single conforming library which one could use. Unfortunately that world does not even approximately exist in C++, and to think it does, and therefore there is no need to have a C++ standard library, as opposed to 100% conformant C++ libraries, such as a 100% conformant reference implementation of the current C++ standard library, or of 100% conformant third party libraries like Boost, is just wishful thinking. I want to also point out to you that even implementations which are, supposedly, 100% conformant to the particular language, such as Sun's Java JRE or Microsoft's .NET implementation, ship automatically with a set of libraries which may be called the standard library for that "language". Do you think that they should not, but rather say that there is a bunch of libraries out here somewhere, presumably on the Internet, and if you the programmer want to use any of them you can just download them and set them up accordingly ? Even in that world of supposedly perfect conformance I think you will find that many will argue that having a set of libraries deemed standard is an advantage to the programmer which must use the "language" in creating other libraries and applications.
Edward Diener wrote:
Robert Ramey wrote:
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++.
I think you are arguing from an emotional perspective which feels that there is no necessity to have standard libraries as long as libraries are implemented in a C++ standard conforming way. The minimalist approach feels good to you.
Well, I plead guilty to the preference for minimalism. But DAMN IT - I'm NOT emotional about it. I don't think that the idea of the standard library is detramental - In fact I've conceded the point that the fact it has the "official sanction" is helpful in a number of organizations. But I just don't think its really very effective in achieving what I think is the goal - making C++ more widely useful. Also I think it creates the impression that efforts underway to make C++ more widely useful than I think they could be.
It is a nice ideal but in practical use fails because of the reality of compiler conformance. I too would love to have all compilers 100% conformant to the C++ standard. In an ideal world this would be so, and therefore a library which is 100% conformant would automatically work with any library which was 100% conformant, and therefore specifying a standard library would be a moot point, as long as there were a single conforming library which one could use.
This is more or less my line of reasoning.
Unfortunately that world does not even approximately exist in C++, and to think it does, and therefore there is no need to have a C++ standard library, as opposed to 100% conformant C++ libraries, such as a 100% conformant reference implementation of the current C++ standard library, or of 100% conformant third party libraries like Boost, is just wishful thinking.
Ahhh - and why is that? why is it so hard to have a 100% conformant compiler that no one has been able to it. That is another question we should be asking ourselves. As you note - this is the key source of the difficulty. And its even worse. Given two 100% conforming compilers, there are areas in the language which are undefined and left to the implementors. Many of these don't effect language semantics - but some do. So even with two 100% conformant compilers there is not guarentee that the same library can be compiled on both with the same results. And that's a problem. Having each vendor tweak his library around this is A solution. But not a very satisfactory one as far as I'm concerned. Hmmm, so, maybe I've answered my own original question here. 100 % comformant compilers cannot be guarenteed to be equivalent - so a vendor MUST include implementation of a standard library which he has verified will work on his compiler. Of course I'm not really happy with that answer - it doesn't help me guarentee portability of my own libraries as I would like - but it IS an answer and probably the "real" one. Oh Well.
I want to also point out to you that even implementations which are, supposedly, 100% conformant to the particular language, such as Sun's Java JRE or Microsoft's .NET implementation, ship automatically with a set of libraries which may be called the standard library for that "language". Do you think that they should not, but rather say that there is a bunch of libraries out here somewhere, presumably on the Internet,
I have no issue with a bunch of libraries being shipped with a compiler. It's very convenient to have pre-build libraries. I use MFC this way all the time. God help me if I had to build it. But my question is "what is thebenefit of having a ""standard library" defined when there is a free working implementation. After - the free working implementation IS a definition of the API. Robert Ramey
Robert Ramey wrote:
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.
The fact that MFC is the right toolkit for the job is very arguable. MFC is probably the worst toolkit ever designed for C++. It was only successful because it's a layer which gives access to Microsoft's platform, Windows, which for some reason got very implanted on the market. Therefore people wanting to program for Microsoft's platform use Microsoft's tools, and MFC is what they have.
On 2006-10-09, Robert Ramey <ramey@rrsd.com> wrote:
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.
Yes, the majority of the market place doesn't care about the difference between standard and de-facto standard. But achieving true de-facto standard status means your library must ship with the development environments used by the majority of users. In practice the only way to achieve de-facto standard level market penetration is to in fact to become standardized [*] Just look a the level of STL adoption before it was *both* standardized and shipped by Microsoft. Steve [*] Unless of course you happen to have an OS monopoly.
"Steve Hutton" <shutton@featurecomplete.com> wrote in message news:egf8f3$59i$1@sea.gmane.org...
On 2006-10-09, Robert Ramey <ramey@rrsd.com> wrote:
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.
Yes, the majority of the market place doesn't care about the difference between standard and de-facto standard. But achieving true de-facto standard status means your library must ship with the development environments used by the majority of users. In practice the only way to achieve de-facto standard level market penetration is to in fact to become standardized [*]
Just look a the level of STL adoption before it was *both* standardized and shipped by Microsoft.
This begs the question of how can we get compiler suppliers to include "a copy" of boost with their compilers? That would certainly remove the single largest barrier to adoption, would it not? It certainly would in the company that I just joined. Are there any on this list that work for MS that would be able to comment on this possibility? Herb Sutter? What about those actively involved in gcc development/support, what would it take to make this happen? What other compiler mfr's are out there? Then we'd need to define just what is "a copy" of boost. Would it be a particular release? Some accomodation of compiler release schedules and processes would be required no doubt. Any comments? Jeff Flinn
Jeff F wrote:
This begs the question of how can we get compiler suppliers to include "a copy" of boost with their compilers? That would certainly remove the single largest barrier to adoption, would it not? It certainly would in the company that I just joined.
Borland used to do that, but since it was a "third party library" and not officially supported, and a little out of date (inevitable), I'm not sure how much it helped. Sigh :-( John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:009f01c6ec90$40477b30$6d401b56@fuji...
Jeff F wrote:
This begs the question of how can we get compiler suppliers to include "a copy" of boost with their compilers? That would certainly remove the single largest barrier to adoption, would it not? It certainly would in the company that I just joined.
Borland used to do that, but since it was a "third party library" and not officially supported, and a little out of date (inevitable), I'm not sure how much it helped. Sigh :-(
Yes, the key is that it be somehow "supported" via pass-through to this mailing list, and be kept reasonably up. It's kind of a chicken and egg scenario - if the big customers asked for it MS, et al would do it, but getting it into the big orgs is difficult without having access through the compiler mfr's. I doubt we'd want to use borland as a poster child in this endeavor. :( Thanks, Jeff Flinn
participants (7)
-
Ames Andreas -
Edward Diener -
Jeff F -
John Maddock -
loufoque -
Robert Ramey -
Steve Hutton