Boost libraries after C++0x acceptance
Hi, I am wanting to know what is going to happen to the boost libraries (eg. boost.regex, boost.filesystem) once the standard C++ implementation is released. Are these libraries then going to be deprecated/disappear from boost thus everyone uses the one available in the standard or will boost authors "still" keep developing and improving/enhancing the them as part of boost (which actually IMHO will be a good thing because boosters can then retain, introduce and enhance features that the standard might not want to accept). What do you think? Also boost libraries that would have been accepted into the standard will vendors (eg. dinkumware) likely to implement their own versions or use the boost implementations instead of reinventing the wheel? Thanks Shams
Shams wrote:
Hi,
I am wanting to know what is going to happen to the boost libraries (eg. boost.regex, boost.filesystem) once the standard C++ implementation is released.
All I can say about Boost.Regex is that it's not going away anytime soon.
Also boost libraries that would have been accepted into the standard will vendors (eg. dinkumware) likely to implement their own versions or use the boost implementations instead of reinventing the wheel?
Dinkumware have written their own versions, G++ has pinched some of our code, but basically are maintaining their own version, I don't know what other vendors will do. John.
On Oct 8, 2006, at 1:25 AM, Shams wrote:
Are these libraries then going to be deprecated/disappear from boost thus everyone uses the one available in the standard or will boost authors "still" keep developing and improving/enhancing the them as part of boost (which actually IMHO will be a good thing because boosters can then retain, introduce and enhance features that the standard might not want to accept). What do you think?
None of the Boost libraries will be going away any time soon, for sure. For my own libraries, I would like to start forwarding to the C+ +0x equivalents when they become available, and phase out the Boost versions over time. The Boost versions need to stick around for a while to maintain backward compatibility, but we should be encouraging users to use the standardized versions. The last thing we want is to be competing against the standard, because that's not our place. Doug
Maybe someone could clarify something for me. My understanding of the C++ standard for libraries is that the interface and semantics are defined by the standard but that actual implementation is purposely left undefined. Hence, adding say regex to the standard doesn't add any code to the standard. It just certifies that anything that claims to be compatible with the C++ regex standard works as the standard says it does. So, acceptance of anything into the standard in no way makes the current boost (or any other) obsolete. As a current example, we see standard collections in the standard (vector, list, etc...) but we see a number of (complementary, competing?) implementations like dinkumware, STLPort, etc. Apparently this is source of some confusion - there was a post recently from a user whose legal department was concerned about the copyright issues related to using code not in the library standard. I believe this is due to a mis-understanding of this difference and that this mis-understanding is common. Now all this raises the key point that has been bothering me for some time. What is the point of having a library standard anyway? Suppose we have a library - take regex for example. The library is developed and is suitable for wide usage and hence there is an interest that it "be included in the standard". I'm not sure but I suspect that the motivation is that this code should be "universally available" accross all C++ environments. But the regex library has a boost license. This license is specifically designed minimize (to zero if possible) any restrictions on its usage. It is also designed to be be compatible with the widest number of C++ environments and specifically with any conforming C++ compiler (which is a different standard). Hence, its already "universally available". To summarize, regex implementation is compatable with any standard conforming C++ compiler. Hence it is available with any such compiler. Including or excluding it from any C++ LIBRARY standard will in no way affect it's utility. Finally, given the fact that there is a free implementation already available, what is the point and/or incentive to make another one that conforms with the standard. This is especially true now that the library standard is much influenced by the current implementations of the proposals. Originally, the concept of a "standard library" was to permit portability accross operating systems and cpus by providing a common layer which would hide the differing implementation detail requred by the differeing underlying environment. This rationale doesn't apply in the case of something like regex whose implementation doesn't depend on the os or cpu but rather on the standard conformance of the C++ compiler. All this leads me to conclude that the current focus on the "standard C++ library" leads to a mis-direction of resources and efforts. I think such efforts would be better directed to other areas. I would like to see C++ be made more portable. This means addressing some things which are currently undefined and/or ambiguous like handling of DLLS, order of initalization of static instances, template instantiation in the presence of code optimization, results of undefined operations, etc. Also there are a number of C++ features which seem to be very hard to implement correctly - judging from the variations of compiler behavior in certain areas. These should be looked at as well. I would like to see things get to the point where a) I could know that if I compiler and test my program in one environment I can be "sure" that it will run the same when I re-compile it and re-run it in another. b) Any "library code" implemenation will be portable as in a) above. I see things like the addition of concepts to C++ moving away from the direction I think C++ has to go. I do realize the benefits and the appeal of these kinds of additions - and specifically of the addition of concepts into the language - but I fear that the net effect adding even more complexity to C++ will result in a language which is overall harder to use rather than easier. Robert Ramey Douglas Gregor wrote:
On Oct 8, 2006, at 1:25 AM, Shams wrote:
Are these libraries then going to be deprecated/disappear from boost thus everyone uses the one available in the standard or will boost authors "still" keep developing and improving/enhancing the them as part of boost (which actually IMHO will be a good thing because boosters can then retain, introduce and enhance features that the standard might not want to accept). What do you think?
None of the Boost libraries will be going away any time soon, for sure. For my own libraries, I would like to start forwarding to the C+ +0x equivalents when they become available, and phase out the Boost versions over time. The Boost versions need to stick around for a while to maintain backward compatibility, but we should be encouraging users to use the standardized versions. The last thing we want is to be competing against the standard, because that's not our place.
Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Robert Ramey" <ramey@rrsd.com> writes:
Maybe someone could clarify something for me.
My understanding of the C++ standard for libraries is that the interface and semantics are defined by the standard but that actual implementation is purposely left undefined.
Hence, adding say regex to the standard doesn't add any code to the standard.
I don't know what you mean by "add code to the standard."
It just certifies that anything that claims to be compatible with the C++ regex standard works as the standard says it does.
No, it says that any C++ implementation that claims to be standard compliant contains a conforming regex implementation. There have as yet been no moves toward "subsetting" of the C++ standard (other than the "hosted"/"non-hosted" distinction -- look it up if you care). Either an implementation provides everything the standard specifies, and can therefore claim compliance, or not. There's not going to be a separate "C++ regex standard." -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Hence, adding say regex to the standard doesn't add any code to the standard.
I don't know what you mean by "add code to the standard."
The standard include the implementation itself. Only the interface that any implemenation has to adhere to.
It just certifies that anything that claims to be compatible with the C++ regex standard works as the standard says it does.
No, it says that any C++ implementation that claims to be standard compliant contains a conforming regex implementation. There have as yet been no moves toward "subsetting" of the C++ standard (other than the "hosted"/"non-hosted" distinction -- look it up if you care). Either an implementation provides everything the standard specifies, and can therefore claim compliance, or not. There's not going to be a separate "C++ regex standard."
OK but this goes to the heart of my question. Suppose I start my new compiler company and I write a C++ compiler which correctly translate C++ language as defined by the C++ standard to some machine language. I don't know if there is any official designation for such a program such as "standard conformant C++ compiler" but that's what we'll call it here. Now I write the low-level code to implement things like fopen, etc in terms of the API of the OS it's going to run on. Its not a "conformant C++ implementation" because it doesn't include all the libraries. So, I just add STLPort and Boost libraries - which work with any "standard conformant C++ compiler". Now I have a "conformant C++ implementation". So once there exists a compiler which correctly implements the C++ language - the existence of a "conformant C++ implementation" is guarenteed. To summarize, having a) "standard conformant C++ compiler" b) a library implementation which is freely availble and depends only on having a above is equivalent to having "conformant C++ implementation" for Regex (and other libraries as well of course), we already have b) above - so what's the point "adding it to the standard" - which seems to me a lot of work for very little practical benefit. Robert Ramey
Robert Ramey wrote:
David Abrahams wrote:
Hence, adding say regex to the standard doesn't add any code to the standard.
I don't know what you mean by "add code to the standard."
The standard include the implementation itself. Only the interface that any implemenation has to adhere to.
It just certifies that anything that claims to be compatible with the C++ regex standard works as the standard says it does.
No, it says that any C++ implementation that claims to be standard compliant contains a conforming regex implementation. There have as yet been no moves toward "subsetting" of the C++ standard (other than the "hosted"/"non-hosted" distinction -- look it up if you care). Either an implementation provides everything the standard specifies, and can therefore claim compliance, or not. There's not going to be a separate "C++ regex standard."
OK but this goes to the heart of my question.
Suppose I start my new compiler company and I write a C++ compiler which correctly translate C++ language as defined by the C++ standard to some machine language.
I don't know if there is any official designation for such a program such as "standard conformant C++ compiler" but that's what we'll call it here.
Now I write the low-level code to implement things like fopen, etc in terms of the API of the OS it's going to run on.
Its not a "conformant C++ implementation" because it doesn't include all the libraries. So, I just add STLPort and Boost libraries - which work with any "standard conformant C++ compiler". Now I have a "conformant C++ implementation". So once there exists a compiler which correctly implements the C++ language - the existence of a "conformant C++ implementation" is guarenteed.
There's nothing wrong with using STLPort as the C++ standard library, as long as it is conformant and the particular compiler implementation is able to use it without errors. Borland already did that in fact in the past. However I still do not think it is "guaranteed" unless the 3rd party C++ standard library is guaranteed to be conformant along with the compiler.
"Robert Ramey" <ramey@rrsd.com> writes:
To summarize, having
a) "standard conformant C++ compiler" b) a library implementation which is freely availble and depends only on having a above
is equivalent to having "conformant C++ implementation"
It's not enough to have a library implementation. The library has to implement the specification of the C++ standard. I'm not sure how close STLPort is these days. It's probably not far, though.
for Regex (and other libraries as well of course), we already have b) above - so what's the point "adding it to the standard" - which seems to me a lot of work for very little practical benefit.
There are lots of people who don't have permission to use any libraries that aren't either standard or shipped by Microsoft. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
for Regex (and other libraries as well of course), we already have b) above - so what's the point "adding it to the standard" - which seems to me a lot of work for very little practical benefit.
There are lots of people who don't have permission to use any libraries that aren't either standard or shipped by Microsoft.
Yeah, I concur with that. In my experience, there's still alot of folks that can't use Boost because they are basically required to *buy* the things they use for development or for some other legal reasons I could never understand. Personally I think it's silly, but executives tend to put the lawyers concerns above developer convenience. So putting something in the standard opens the door to a whole world of developers that won't have access otherwise. Also, stuff in the standard will have training courses, books, and other resources that will not be devoted to many or most Boost libraries. While I realize there are companies that provide Boost training and a few Boost related books....many, many more will provide training on the standard libs. Jeff
Jeff Garland <jeff@crystalclearsoftware.com> writes:
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
for Regex (and other libraries as well of course), we already have b) above - so what's the point "adding it to the standard" - which seems to me a lot of work for very little practical benefit.
There are lots of people who don't have permission to use any libraries that aren't either standard or shipped by Microsoft.
Yeah, I concur with that. In my experience, there's still alot of folks that can't use Boost because they are basically required to *buy* the things they use for development or for some other legal reasons I could never understand.
FWIW, Boost Consulting will be happy to sell them a DVD. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Jeff Garland <jeff@crystalclearsoftware.com> writes:
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
for Regex (and other libraries as well of course), we already have b) above - so what's the point "adding it to the standard" - which seems to me a lot of work for very little practical benefit.
There are lots of people who don't have permission to use any libraries that aren't either standard or shipped by Microsoft.
Yeah, I concur with that. In my experience, there's still alot of folks that can't use Boost because they are basically required to *buy* the things they use for development or for some other legal reasons I could never understand.
FWIW, Boost Consulting will be happy to sell them a DVD.
I bet this would actually satisfy the concerns of at least a few companies. Their concerns are really based on subjective concerns and having a physical DVD with a printed label and a signed licence agreement might be all they need. Actually, I think that would be really, really helpful if it could be justified to more heavily promote such a product. I would hope, but of course don't know, that such promotion would pay for itself in sales and result in a wider distribution of the "boost way". I'm astounded at the number of C++ programmers I run accross that have never even heard of boost. Development of a "profit-making" arm - sort of a mini RedHat would be very helpful. I suppose that Boost Consulting already fullfills this role to the extent that it can be profitable. Robert Ramey
Robert Ramey wrote:
I'm astounded at the number of C++ programmers I run accross that have never even heard of boost.
There are some programmers which have never heard of the standard containers or even never heard of templates. Given the low quality of web tutorials, some books and even the low quality of some courses in college, you can't expect all people to know the right way to code. Maybe some evangelization of the profits of modern C++ is what's really needed to spread boost more.
On 10/9/06, Robert Ramey <ramey@rrsd.com> wrote:
I'm astounded at the number of C++ programmers I run accross that have never even heard of boost. Well, it not only the boost problem. I personally met few people who had number of years of C++ development and never heard about STL. -- Best regards, Zigmar
Robert Ramey wrote:
What is the point of having a library standard anyway?
I have always viewed the importance of a library standard as a means of specifying that an implementation which supports the language must provide the library also. This automatically creates a common set of functionality for all implementations of the language. I view that as a good thing but it certainly does not mean that the library standard must be the only library which works for nearly all implementations, as Boost has shown.
Edward Diener wrote:
Robert Ramey wrote:
What is the point of having a library standard anyway?
I have always viewed the importance of a library standard as a means of specifying that an implementation which supports the language must provide the library also.
This automatically creates a common set of functionality for all implementations of the language. I view that as a good thing ...
no disagreement there. My question is how to guarentee this. There are at least two options: a) tweak the library to fit the compiler and meet the standard b) all of the following: i) requiring a language conforming implementation for the library ii) provide a reference implementation of the library. My view is that the current situation tolerates and perhaps encourages the a) while creating a huge amount of work in creating the standards. I believe that this work would better be invested elsewhere. Like actually bringing the compiler(s) to conformance.
but it certainly does not mean that the library standard must be the only library which works for nearly all implementations, as Boost has shown.
The library standard doesn't "work". It can't. It's not code. The standard doesn't include an implemenation. And once we have a reference implementation which can be compiled on a language conformant compiler, what is gained from the work required to add it to the standard? Robert Ramey
Robert Ramey wrote:
The library standard doesn't "work". It can't. It's not code. The standard doesn't include an implemenation. And once we have a reference implementation which can be compiled on a language conformant compiler, what is gained from the work required to add it to the standard?
Wider audience, multiple competing implementations, availability. You can depend on the standard library being available for use even if for administrative/legal/whatever reasons no third party code is allowed on a project.
Peter Dimov wrote:
Robert Ramey wrote:
The library standard doesn't "work". It can't. It's not code. The standard doesn't include an implemenation. And once we have a reference implementation which can be compiled on a language conformant compiler, what is gained from the work required to add it to the standard?
Wider audience,
perhaps. Actually, I see this as the only real benefit. Instead of "wider audience" I would call it something like of "imprimateur of people who know what they are doing". That is, being accepted into the standard make it "acceptable" to use. Its sort of a "certification". But since it doesn't include implementation, the certification has to be limited. Of course I feel confident in making my own decision as to whether a particular library is a good candidate for use - but I don't work for a larger organization which may really need this kind of thing. Still its an awfully expensive "seal of approval".
multiple competing implementations, availability.
The existance of a the standard doesn't affect these. Remember, I'm presuming the existence of a free, conforming C++ implementation of the library in question.
You can depend on the standard library being available for use
Remember, I'm presuming the existence of a free, conforming C++ implementation of the library in question.
even if for administrative/legal/whatever reasons no third party code is allowed on a project.
It was precisely the posting of a question regarding this which clarified the question in my own mind. The existence of a standard in no way effects the "third party" status of any particular implmentation. Note that all the compilers we currently use are shipping with "third party" library implementions. (hmm maybe g++ doesn't fit here - but then its not even clear who the "first party" is here). Of course, this fact has to be kept a secret from the legal community. Robert Ramey
Robert Ramey wrote:
It was precisely the posting of a question regarding this which clarified the question in my own mind.
The existence of a standard in no way effects the "third party" status of any particular implmentation.
It does (from legal and support point of view) since there is a single supplier, the compiler vendor. If the vendor has been cleared for use (and you have to have a compiler cleared for a project), you get the standard library for free, but not Boost, you need a separate uphill battle for that. Or so I hear.
Peter Dimov wrote:
Robert Ramey wrote:
It was precisely the posting of a question regarding this which clarified the question in my own mind.
The existence of a standard in no way effects the "third party" status of any particular implmentation.
It does (from legal and support point of view) since there is a single supplier, the compiler vendor. If the vendor has been cleared for use (and you have to have a compiler cleared for a project), you get the standard library for free, but not Boost, you need a separate uphill battle for that. Or so I hear.
You may have heard right - I wouldn't know. It would sure be a disappointing to find that huge efforts to define the interface of an ever expanding library are being expended just to meet the requirements imposed by a group of lawyers who are not knowledgable about what's really going on. BTW - all the compiler vendors require customer's accept a disclaimer that the their code and/or libraries have any errors and require that one sign a waiver absolving them of any errors in their code. I doubt that compiler vendors guarentee to pay you're legal costs of something in the library turns out to have been which violates a patent. I can't see whether or not something is in the standard would effect the legal issues involved - as the standard addresses interface - not implementation. Some lawyers may believe that the fact something is or is not in the standard may have some legal implications. But I doubt that such beliefs have any real foundation. Of course the fact that they believe may have real implications - but its not a great rationale for such an undertaking. Robert Ramey
Peter Dimov wrote:
Robert Ramey wrote:
The library standard doesn't "work". It can't. It's not code. The standard doesn't include an implemenation. And once we have a reference implementation which can be compiled on a language conformant compiler, what is gained from the work required to add it to the standard?
Wider audience, multiple competing implementations, availability. You can depend on the standard library being available for use even if for administrative/legal/whatever reasons no third party code is allowed on a project.
Right, but standardization has disadvantages. It's set in stone in the sense that changes in future standards necessarily have backwards compatibility as an overriding concern. With add-on libraries, things can evolve in a much more reasonable manner - if someone is really tied to old behavior they can use an older version of boost. Consider the fiasco with std::vector<bool>. If it had been a boost library, it would have been fixed years ago! Cheers, Ian McCulloch
Robert Ramey wrote:
Edward Diener wrote:
Robert Ramey wrote:
What is the point of having a library standard anyway?
I have always viewed the importance of a library standard as a means of specifying that an implementation which supports the language must provide the library also.
This automatically creates a common set of functionality for all implementations of the language. I view that as a good thing ...
no disagreement there. My question is how to guarentee this. There are at least two options:
a) tweak the library to fit the compiler and meet the standard b) all of the following: i) requiring a language conforming implementation for the library ii) provide a reference implementation of the library.
My view is that the current situation tolerates and perhaps encourages the a) while creating a huge amount of work in creating the standards. I believe that this work would better be invested elsewhere. Like actually bringing the compiler(s) to conformance.
No one is against doing the work of bringing the compiler to conformance, but providing a C++ standard library which works with the compiler is part of that conformance also. Many C++ compilers use a 3rd party C++ standard library, and there is nothing wrong with that. I think that you want the C++ standard committee in b) ii) to provide a reference implementation of the library for all compiler vendors to use. Is that your argument ?
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? If there value, is it worth the cost? OK two questions. So far, I'm thinking the answers are: very little, and no.
I think that you want the C++ standard committee in b) ii) to provide a reference implementation of the library for all compiler vendors to use.
Actually what I'm thinking is the following. a) Some smart guys creat a library like Regex or a set of libraries like Boost. b) the librar(ies) are free and work with all compilers which correctly implement the C++ language. c) Compiler vendors wanting to sell more programs, Advertise on the box "Compiles all legal C++ programs - including all Boost Libraries" and they spend their efforts fullfiling that claim. d) C++ commitee invests its efforts in clarifying issues which inhibit compiler vendors from fullfilling c). I'm not sure there is a huge argument here. Some compiler vendors are already advertising "boost compatible" on the box. I've noticed at least one poster on the developer's list working to make his companies compiler specifically compliant to be able to build boost and pass all tests. I personally got a call from borland asking me if I wanted any help (Damn - I wish I hadn't thrown away that message!). Adding something to the standard isn't going to change that one way or the other.
I think that you want the C++ standard committee in b) ii) to provide a reference implementation of the library for all compiler vendors to use.
My concern is that the emphasis on making the standard include more and more libraries provides relatively little value in comparison to the effort invest and that resources would be better invested in other areas which I mentioned previously. Robert Ramey
Robert Ramey wrote:
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?
That which was mentioned: as part of the language standard, I, as an application programmer, can rely on the library being available and usable on all conformant implementations, without any setup for the build system to reference the library, without any special troubles in getting the library itself to compile, without having to wrestle any legal department to get it to work, without having to beg any college course administration to install it - in short, I can use it just as easily as I can use vector and string now. You may not think that is much added value. My experiences, both first- and second-hand, tell me otherwise.
If there value, is it worth the cost?
What, exactly, is the cost in the scenario you described? There is a freely available reference implementation, so the additional effort for the compiler company consists of including this implementation in the distribution. And doing some additional testing, perhaps, but if the existing implementation has a good test suite itself, that shouldn't be too much work. So yes, I think it is worth the cost. I want to say more, but my brain's kinda foggy. Sebastian
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 and all C++ programmers know that if they use that library in their code it must work correctly on any other conforming implementation. 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. 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. 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 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 which does support a 3rd party library to one that does not support a 3rd party library will fail. 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.
Edward Diener wrote:
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.
I see no reason why the compiler vendor would choose to not support a feature, which prevents it from claiming conformance, but would choose to support a library which was just added to the standard in order to be compliant with it.
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
On 10/8/06, Robert Ramey <ramey@rrsd.com> wrote:
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.
This whole discussion sounds analogous to the debate over whether it breaks encapsulation to have member functions of a class that could equally be written in terms of its interface as free functions. So, in effect, what Rob is trying to say is that adding libraries, such as regex, that can be "implemented in terms of the interface" (ie the language, in this case) to the "class" (the standard library), breaks the "encapsulation", or integrity, of the standard itself :-)
From a purist point of view I can see his point, and tend to agree with it. I also see where he is coming from on the practical side (spend more time, with more motivation, to improve langauage compliance).
However, from a pragmatic perpective, I still favour adding the libraries to the standard (in terms of interface and gaurantees). This is because, as others have said, in many (especially larger) organisations, policies governing adoption of third party libraries can make it difficult - if not impossible - to use even as open and free library sets as Boost's. Where I am now, even though Boost was on their "approved list", use in my team had been put off because of the overhead of adding it to our source control and our projects. We are finally using it now, but still only those libraries that are implemented in headers. Then there are the larger number of developers/ team leaders/ managers who have either not heard of Boost, or are not familiar enough with it to think it worth taking on - and quite a few that I have met have negative preconceptions about it that can be difficult to overcome. All these obstacles would be drastically reduced or eliminated when talking about standard libraries. Anyway, that's my own view, for what it's worth. Best regards, [)o IhIL..
Phil Nash wrote:
However, from a pragmatic perpective, I still favour adding the libraries to the standard (in terms of interface and gaurantees). This is because, as others have said, in many (especially larger) organisations, policies governing adoption of third party libraries can make it difficult - if not impossible - to use even as open and free library sets as Boost's. Where I am now, even though Boost was on their "approved list", use in my team had been put off because of the overhead of adding it to our source control and our projects. We are finally using it now, but still only those libraries that are implemented in headers. Then there are the larger number of developers/ team leaders/ managers who have either not heard of Boost, or are not familiar enough with it to think it worth taking on - and quite a few that I have met have negative preconceptions about it that can be difficult to overcome. All these obstacles would be drastically reduced or eliminated when talking about standard libraries.
So we should put boost into the standard library because of the stupidity of some companies or team leaders ?
loufoque wrote:
So we should put boost into the standard library because of the stupidity of some companies or team leaders ?
Some of those "companies" have no choice. For example a government contractor must comply with regulatory restrictions, many of which correspond to some form of international or US standards. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera writes:
loufoque wrote:
So we should put boost into the standard library because of the stupidity of some companies or team leaders ?
Some of those "companies" have no choice. For example a government contractor must comply with regulatory restrictions, many of which correspond to some form of international or US standards.
< someone 'way in the back raises a hand > It can be much worse. When working on classified projects (at least here in the USA), _any_ software brought in from "outside" has to undergo rigorious inspection and screening; this can take weeks, or even months if one has to go through various other agencies, committees, etc. The process and requirements have nothing whatsoever to do with the contractor, and everything to do with government security regulations. < return to lurk mode > ---------------------------------------------------------------------- Dave Steffen, Ph.D. Software Engineer IV Disobey this command! Numerica Corporation ph (970) 419-8343 x27 fax (970) 223-6797 - Douglas Hofstadter dgsteffen@numerica.us ___________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
Dave Steffen wrote:
Rene Rivera writes:
loufoque wrote:
So we should put boost into the standard library because of the stupidity of some companies or team leaders ?
Some of those "companies" have no choice. For example a government contractor must comply with regulatory restrictions, many of which correspond to some form of international or US standards.
< someone 'way in the back raises a hand >
It can be much worse. When working on classified projects (at least here in the USA), _any_ software brought in from "outside" has to undergo rigorious inspection and screening; this can take weeks, or even months if one has to go through various other agencies, committees, etc.
The process and requirements have nothing whatsoever to do with the contractor, and everything to do with government security regulations.
I don't see that having the interface for such software in a standard would effect this problem. The implementation would have to be screened in any case. Of course if one is using a library which has already been screened in a different or related project, presumably that code - if it hasn't been changed - will be acceptable for the current one. But for that to work one needs to have better portability than we now have. Robert Ramey
Robert Ramey writes:
Dave Steffen wrote:
Rene Rivera writes:
loufoque wrote:
So we should put boost into the standard library because of the stupidity of some companies or team leaders ?
Some of those "companies" have no choice. For example a government contractor must comply with regulatory restrictions, many of which correspond to some form of international or US standards.
< someone 'way in the back raises a hand >
It can be much worse. When working on classified projects (at least here in the USA), _any_ software brought in from "outside" has to undergo rigorious inspection and screening; this can take weeks, or even months if one has to go through various other agencies, committees, etc.
The process and requirements have nothing whatsoever to do with the contractor, and everything to do with government security regulations.
I don't see that having the interface for such software in a standard would effect this problem. The implementation would have to be screened in any case.
Well, the difference is that the standard library comes with the compiler, whereas Boost doesn't; it's one (potentially expensive) process vs. two. I was simply pointing out one extreme case of Rene was saying above: some companies have no choice about the conditions under which they can use Boost, and it's not necessarily because the team leads are stupid. ---------------------------------------------------------------------- Dave Steffen, Ph.D. Software Engineer IV Disobey this command! Numerica Corporation ph (970) 419-8343 x27 fax (970) 223-6797 - Douglas Hofstadter dgsteffen@numerica.us ___________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
On 10/9/06, loufoque <mathias.gaunard@etu.u-bordeaux1.fr> wrote:
Phil Nash wrote:
However, from a pragmatic perpective, I still favour adding the libraries to the standard (in terms of interface and gaurantees). This is because, as others have said, in many (especially larger) organisations, policies governing adoption of third party libraries can make it difficult - if not impossible - to use even as open and free library sets as Boost's. Where I am now, even though Boost was on their "approved list", use in my team had been put off because of the overhead of adding it to our source control and our projects. We are finally using it now, but still only those libraries that are implemented in headers. Then there are the larger number of developers/ team leaders/ managers who have either not heard of Boost, or are not familiar enough with it to think it worth taking on - and quite a few that I have met have negative preconceptions about it that can be difficult to overcome. All these obstacles would be drastically reduced or eliminated when talking about standard libraries.
So we should put boost into the standard library because of the stupidity of some companies or team leaders ?
No, that wasn't my main point - it was just a supporting factor. And I wouldn't necessarily call them all "stupid". Some have good, if misplaced, reasons. My overall point was just, as others have said, to reach a much wider audience. Regards, [)o IhIL..
Phil Nash wrote:
No, that wasn't my main point - it was just a supporting factor. And I wouldn't necessarily call them all "stupid". Some have good, if misplaced, reasons. My overall point was just, as others have said, to reach a much wider audience.
My company (i.e., my boss) is VERY reluctant to rely on third-party software, which includes Boost libraries. If Boost ceased to exist or support new compilers, we would be stuck with a major task of maintaining code, which we did not develop. I'm not saying that this is likely to happen, and I have managed to convince everyone here that Boost is widely accepted and very professionally developed and maintained. However, libraries that are part of a C++ standard give us a reliable guarantee that we can use them in code that will work on new platforms and compilers with no maintenance needed on our part. It may be a lot of work on the part of Boost developers to get their libraries accepted as standard, but I very much appreciate their efforts. I consider their acceptance as a major success. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Phil Nash wrote:
My company (i.e., my boss) is VERY reluctant to rely on third-party software, which includes Boost libraries. If Boost ceased to exist or support new compilers, we would be stuck with a major task of maintaining code, which we did not develop. I'm not saying that this is likely to happen, and I have managed to convince everyone here that Boost is widely accepted and very professionally developed and maintained. However, libraries that are part of a C++ standard give us a reliable guarantee that we can use them in code that will work on new platforms and compilers with no maintenance needed on our part.
I've seen this phenomenon as well. In my view its very misguided. suppose my company needs a shared_ptr. I go to my boss and say "we need a shared_ptr" and "here is one (boost) which is a) provided with source code b) documented c) rigorously and formally tested. d) includes all testing infrustructure e) is compatible with all currently used systems " And the boss says - no don't use that - we have no guarentee that it will be maintained in the future. Here is what I want you to do: a) write our own shared_ptr b) document it - if you have time c) testing - who has time - just add it to our app and that'll be the test d) testing infrasture - we can't use third party libraries e) other systems? - we have our hands full with just our current system. So you do this. Now suppose boost disappears and you have to maintain the shared_ptr yourself. Which is going to be easier to maintain in the future? and what about when you need regex? Are you going to have someone re-write it from scratch? How much is that going to add to the delivery date. The whole issue is really economics of scale. It means a) spending time only on those things that are unique to one's application. b) It means that the work we're doing is more unique and therefore higher value added to the final product. c) This implies having a smaller department with a higher percentage of the employees in the "critical path" of developement. Since this is unique and new stuff . d) This well "seem" more expensive as these employees are likely to be paid somewhat more than average and they will spend time doing things like participating in boost, reading journals and books, running small experiments and going to conferences. "seem" because the extra production and lessing of errors isn't measured - only the "cost per hour of time" is measured and the total time to do a project is considered fixed independent of the methodology. d) This leaves a lot less for the "boss" to do. In fact, you'll need a LOT less "management" when you have a smaller team. e) This conflicts with the fundamental metric by which the bosses performance is measured which is the size of department he can be responsable for without have a visible screw up. f) So in order to address this he has to make his team bigger. He can encroach on some elses territory - but that usually doesn't work as he bumps into another manager with the same problem. He could try to make products which sell more - But then someone has to come up with some new idea - which would upset someone. Even if someone were to do that, it has to be sold to a bunch of departments including a sales/support system which has pretty much lost faith that he can deliver something more or less as promised. Besides, they're bogged down trying to sell and support something that's still not working. The legal department is another log-rolling organization. Their responsability is to be sure they don't get blamed for anything. So they always advise against just about everything regardless of the economic issues involved. So basically, it's better for all the key decision makers to employ an army of slaves spending most of their time re-inventing a crappy version of some existing wheel. Everyone's busy, work is being done things run smoothly. OK - I'm exaggerating - but by how much? There's a reason that large organization, despite the availability of resources ( infinitely greater than boost's) produce so little new stuff in relation to smaller organizations. Robert Ramey
Robert Ramey wrote:
Richard Hadsell wrote:
suppose my company needs a shared_ptr. I go to my boss and say "we need a shared_ptr" and "here is one (boost) which is ...
I agree with you completely, given the scenario of needing some code that Boost offers. But the other alternative is to not use a shared_ptr at all. We would just go on writing code that is not as good, slower, buggier, etc., the way we traditionally write code. The libraries offer better code, but their cost is a risk that would be much reduced, if they were standard libraries. At least that's our perception. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote: Sorry, there was an extra "Richard Hadsell wrote:" that I should have deleted. This version should be clearer.
Robert Ramey wrote:
suppose my company needs a shared_ptr. I go to my boss and say "we need a shared_ptr" and "here is one (boost) which is ...
I agree with you completely, given the scenario of needing some code that Boost offers. But the other alternative is to not use a shared_ptr at all. We would just go on writing code that is not as good, slower, buggier, etc., the way we traditionally write code. The libraries offer better code, but their cost is a risk that would be much reduced, if they were standard libraries. At least that's our perception.
-- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Robert Ramey wrote:
Richard Hadsell wrote:
Phil Nash wrote:
My company (i.e., my boss) is VERY reluctant to rely on third-party software, which includes Boost libraries. If Boost ceased to exist or support new compilers, we would be stuck with a major task of maintaining code, which we did not develop. I'm not saying that this is likely to happen, and I have managed to convince everyone here that Boost is widely accepted and very professionally developed and maintained. However, libraries that are part of a C++ standard give us a reliable guarantee that we can use them in code that will work on new platforms and compilers with no maintenance needed on our part.
I've seen this phenomenon as well. In my view its very misguided.
suppose my company needs a shared_ptr. I go to my boss and say "we need a shared_ptr" and "here is one (boost) which is a) provided with source code b) documented c) rigorously and formally tested. d) includes all testing infrustructure e) is compatible with all currently used systems " And the boss says - no don't use that - we have no guarentee that it will be maintained in the future. Here is what I want you to do:
a) write our own shared_ptr b) document it - if you have time c) testing - who has time - just add it to our app and that'll be the test d) testing infrasture - we can't use third party libraries e) other systems? - we have our hands full with just our current system. So you do this. Now suppose boost disappears and you have to maintain the shared_ptr yourself. Which is going to be easier to maintain in the future?
and what about when you need regex? Are you going to have someone re-write it from scratch? How much is that going to add to the delivery date.
Thanks Robert, I couldn't have expressed that better myself. To take the shared_ptr example: Lets say you extract the subset of Boost that you are using (we have a tool - bcp - especially for this task see http://www.boost.org/tools/bcp/bcp.html), now you have a bunch of "free" code that's been very widely tested over a great many more platforms and compilers than your boss has probably invested in :-) That code isn't going away. No one can take it away from you. You can choose to upgrade to a new version of Boost from time to time if that's what you want, or if you find a problem that's only been fixed in a new version. I see his point in dealing with new compilers: say 10 years down the line (being rather optimistic on how long lived your software will be :-) ), but ask him how many of his current staff will still be around then to maintain a bespoke version ? Sure, no one can make guarentees about third party code, but remember that the chances of commercial produced - closed source - code being supported over that kind of timescale is essentially nil: anyone here remember OWL? I would also point out that developers from several major compiler vendors are known to hang out here from time to time (I can think of folks from Sun, HP and MS for a start). It's heartening to see that these companies care that their products are Boost-compatible. And finally, point your boss towards Adobe or SAP, if these big players are using Boost, there's probably something in it :-) Regards, John Maddock.
John Maddock wrote:
I see his point in dealing with new compilers: say 10 years down the line (being rather optimistic on how long lived your software will be :-) ), but ask him how many of his current staff will still be around then to maintain a bespoke version ? Sure, no one can make guarentees about third party code, but remember that the chances of commercial produced - closed source - code being supported over that kind of timescale is essentially nil: anyone here remember OWL?
Yes I remember OWL. But that probably only shows how old I am :-( The unfortunate aspect of all this talk about how logical it is for companies to use Boost libraries, is that it's logical. But the corporate world is rarely logical. And hence it takes great effort to move it in a logical direction from the bottom up.
And finally, point your boss towards Adobe or SAP, if these big players are using Boost, there's probably something in it :-)
That is likely the biggest factor we can count on for people to use in convincing corporate management to use Boost libraries. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
John Maddock wrote:
I see his point in dealing with new compilers: say 10 years down the line (being rather optimistic on how long lived your software will be :-) ), but ask him how many of his current staff will still be around then to maintain a bespoke version ? Sure, no one can make guarentees about third party code, but remember that the chances of commercial produced - closed source - code being supported over that kind of timescale is essentially nil: anyone here remember OWL?
Yes I remember OWL. But that probably only shows how old I am :-(
The unfortunate aspect of all this talk about how logical it is for companies to use Boost libraries, is that it's logical. But the corporate world is rarely logical. And hence it takes great effort to move it in a logical direction from the bottom up.
I agree...there's alot of decisions that engineers consider silly. But again, engineers are rarely running things. As I said earlier, one nervous lawyer can create alot of trouble in the logic realm.
And finally, point your boss towards Adobe or SAP, if these big players are using Boost, there's probably something in it :-)
That is likely the biggest factor we can count on for people to use in convincing corporate management to use Boost libraries.
Actually, I consider it 'evolution in action'. Eventually the inefficient companies (eg: those that ignore open source and try to build their own) will be unable to compete against their competitors that don't waste their time reinventing stuff. But this can take a very long time. From my perspective it's clear that C++ is losing ground to other languages because the lack of 'standard libraries' provided. I've seen this discussion go on inside more than one company. There's no doubt that large companies embarking on expensive projects feel much more comfortable using tools that are supported by multiple large companies (eg: Java supported by Sun, IBM, et. al.). Multiple large vendors -- it's the safe choice, not necessarily the best. With C++ there are multiple compiler vendors for most platforms. With due respect to Boost Consulting, it's not the same as having IBM providing support (no doubt it's actually better, but companies aren't interested in better service, they're interested in companies with deep pockets that can 'make things right' if serious problems arise). So some companies have problems with Boost b/c of this. And sometimes b/c of customer requirements Boost isn't cheaper. As someone already mentioned, in the US defense industry, where C++ is used extensively, there are requirements about foreign sources that can create issues for using Boost. Each line of code needs to be inspected, etc, etc. If it's in the standard and from someone like MSFT/IBM then this has likely already been done. So that saves time and money. At the end of the story, it may be that the committee can never do enough because languages like Java have libraries that are so extensive and so deeply funded that C++ can never compete with volunteer labor. That said, I like to think that by getting good libraries in the standard we can improve the life of those programmers that can't use Boost. There's no reason why these programmers should have to suffer just b/c their management doesn't get it or there is some other restriction in their environment. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
At the end of the story, it may be that the committee can never do enough because languages like Java have libraries that are so extensive and so deeply funded that C++ can never compete with volunteer labor.
The major problem IMO is that the "volunteer labor" inevitably prefers development for fun to commercially-justified development. This drives inovation, but hurts competition. Where are sockets, database access, etc.? Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
At the end of the story, it may be that the committee can never do enough because languages like Java have libraries that are so extensive and so deeply funded that C++ can never compete with volunteer labor.
The major problem IMO is that the "volunteer labor" inevitably prefers development for fun to commercially-justified development. This drives inovation, but hurts competition. Where are sockets, database access, etc.?
Well, I suppose. In the cases you mention, I think these are just harder problems. These are hard enough that it's best to have a group and groups are harder than single programmers. That said, these are in the pipeline :-) http://asio.sourceforge.net/ http://soci.sourceforge.net/ Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Arkadiy Vertleyb wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
At the end of the story, it may be that the committee can never do enough because languages like Java have libraries that are so extensive and so deeply funded that C++ can never compete with volunteer labor.
The major problem IMO is that the "volunteer labor" inevitably prefers development for fun to commercially-justified development. This drives inovation, but hurts competition. Where are sockets, database access, etc.?
Well, I suppose. In the cases you mention, I think these are just harder problems. These are hard enough that it's best to have a group and groups are harder than single programmers. That said, these are in the pipeline :-)
Right, in the pipeline... just 8 years after Boost was started :-( OTOH, we do have two (!) great regular expression libraries... Can you imagine something like this happenning to Java or C#? IMHO, it's not about not having enough libraries. It's just about not having those particular libraries that are considered most important by the corporate world. The problem is that C++ and, let's say, Java exist in two different dimensions. Java is a product of commercial world, so in the commercial world it is playing on its own territory. Java is developed to be commercially successfull. C++ (at it's current state) is a totaly different animal. It's mostly being developed by the non-commercial entities, like the standard committee, open source movement, etc. So it almost looks like a volonteer research project. And as such, there is a great amount of inovation, but not a lot of ability to compete in the commercial world. Open source is just designed to deliver certain kind of libraries, but not another... So, in the corporate world, I think, C++ is rapidly loosing it's ground. It is still strong, but mostly because of huge amount of legacy code. A lot of new development is being started in either C# or Java. This is a shame, IMO. I do believe that C++ is a much better language... Interestingly, I think recently C++ received some boost from the commercial world. This happened when MSFT (for whatever reason) decided to revamp their C++ compiler. Just try to imagine where C++ community would be now without VC7.1/8.0... I think both inovation and commercial development are equally important. C++ currently has a lot of inovation, but that's it. Because of this it's loosing the competition. The only way out IMO is to somehow exploit whatever commercial interest in C++ there exist out there. I have no idea how to achieve this and whether it is possible at all, but if this doesn't happen we will all need to switch to C# or Java (at least to earn our living) in not so distant future :-( Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Arkadiy Vertleyb wrote:
Interestingly, I think recently C++ received some boost from the commercial world. This happened when MSFT (for whatever reason) decided to revamp their C++ compiler. Just try to imagine where C++ community would be now without VC7.1/8.0...
Unfortunately for .Net programming, which is certainly the programming which most companies will do from now on with Microsoft's Visual Studio, both C# and VB .Net were given a 4 year headstart over C++. Even after 4 years, with the release of .Net 2.0 and Visual Studio 2005, there are still problems with C++ .Net programming which Microsoft has still not ironed out and if one does web application programming using ASP .Net one can not use C++ directly for the code which manipulates the web page, but only C# or VB .Net. If one reads the ads for programmers in .Net, 95%+ of them are for C#, 4.9% of them are for VB .Net and the rest is for C++. Actually I have never seen a single ad anywhere on Internet job boards for C++ .Net programming, but I imagine one exists somewhere. While Microsoft can be commended for raising the level of their compiler in VC7.1 and VC8, the truth is that where it matters commercially almost no new future work is being done in C++ and .Net, and this is directly the "fault" of Microsoft.
Edward Diener skrev:
Arkadiy Vertleyb wrote:
While Microsoft can be commended for raising the level of their compiler in VC7.1 and VC8, the truth is that where it matters commercially almost no new future work is being done in C++ and .Net, and this is directly the "fault" of Microsoft.
Or their hopefully failing purpose. I think the game here is as follows: 1. a lot of C++ code is out there 2. we want those projects tied up in, and eventually converted to our proprietary platform called .NET. 3. to convert those projects to .NET we need C++.net (i.e. managed C++) so they can be tempted to move in our direction 4. we create a set of C++ bindings to .NET (vs 2003) 5. oops, it failed --- almost nobody moved since it looked ugly 6. make a new one that looks better, is even less C++ compliant (who cares, we sure don't) , but it _must_ look better (vs 2005) 7. but what about those that actually used vs2003 - what about them; they can port, doesn't cost us anything, and they are few and already tied up (remember OWL folks) 8. vision - C++.NET road map ends when we don't think we can move more projects For those who has moved, let us hope I am wrong. Bottom line: MS efforts to support C++ on the .NET platform is not designed to benefit the C++ community. It is designed to be a vampire, hopefully it stays small as a mosquito. --- Bjørn Roald
Bjørn Roald wrote:
Edward Diener skrev:
Arkadiy Vertleyb wrote:
While Microsoft can be commended for raising the level of their compiler in VC7.1 and VC8, the truth is that where it matters commercially almost no new future work is being done in C++ and .Net, and this is directly the "fault" of Microsoft.
Or their hopefully failing purpose. I think the game here is as follows:
<snip Slashdot-esque Microsoft rant> Microsoft bashing doesn't have a place on this list. Please stop. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler skrev:
Bjørn Roald wrote:
Edward Diener skrev:
Arkadiy Vertleyb wrote:
While Microsoft can be commended for raising the level of their compiler in VC7.1 and VC8, the truth is that where it matters commercially almost no new future work is being done in C++ and .Net, and this is directly the "fault" of Microsoft.
Or their hopefully failing purpose. I think the game here is as follows:
<snip Slashdot-esque Microsoft rant>
Microsoft bashing doesn't have a place on this list. Please stop.
Ok, sorry. I got carried away. I guess I felt the indirect promotion of managed C++ did not have a place here. Also I may add that there are a lot of good people at MS working for and with ISO C++. I never intended to alienate them. Bjørn
"Bjørn Roald" <bjorn@4roald.org> wrote Edward Diener skrev:
Arkadiy Vertleyb wrote:
While Microsoft can be commended for raising the level of their compiler in VC7.1 and VC8, the truth is that where it matters commercially almost no new future work is being done in C++ and .Net, and this is directly the "fault" of Microsoft.
For the record, these are not my words. What I was saying is that the fact that MSFT dramatically improved their compiler helped tremendously C++ comunity. IMHO, if this hadn't happenned there would have been nothing now to talk about. I also said nothing about .Net development and managed C++. What I meant is the regular (standard-complying) C++ compiler. Regards, ARkadiy
"Bjørn Roald" <bjorn@4roald.org> wrote Edward Diener skrev:
Arkadiy Vertleyb wrote:
While Microsoft can be commended for raising the level of their compiler in VC7.1 and VC8, the truth is that where it matters commercially almost no new future work is being done in C++ and .Net, and this is directly the "fault" of Microsoft.
For the record, these are not my words. Ok, you are correct. I must be more careful when I cut stuff from
Arkadiy Vertleyb wrote: postings. Sorry
What I was saying is that the fact that MSFT dramatically improved their compiler helped tremendously C++ comunity. Agreed IMHO, if this hadn't happenned there would have been nothing now to talk about.
There is always the weather ;-) Well, I feel like this is a stretch. For one thing, there would have been more room for competitors on the Windows platform, so who knows.
I also said nothing about .Net development and managed C++. I never though you did, I was just not careful enough, so your name was not cut out of my posting. What I meant is the regular (standard-complying) C++ compiler.
Good regards, Bjørn
Bjørn Roald wrote:
Edward Diener skrev:
Arkadiy Vertleyb wrote:
While Microsoft can be commended for raising the level of their compiler in VC7.1 and VC8, the truth is that where it matters commercially almost no new future work is being done in C++ and .Net, and this is directly the "fault" of Microsoft.
Or their hopefully failing purpose. I think the game here is as follows:
1. a lot of C++ code is out there 2. we want those projects tied up in, and eventually converted to our proprietary platform called .NET. 3. to convert those projects to .NET we need C++.net (i.e. managed C++) so they can be tempted to move in our direction 4. we create a set of C++ bindings to .NET (vs 2003) 5. oops, it failed --- almost nobody moved since it looked ugly
It failed because of the infamous loader lock bug ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechar... ). The syntax has been made better and easier to use from Managed C++ to C++/CLI, but that has little to do with the failure.
Jeff Garland wrote:
From my perspective it's clear that C++ is losing ground to other languages because the lack of 'standard libraries' provided.
<snip> I'm concerned that the lack of "standard libraries" is in part attributable to features of the language which make it hard to "build once - build/run anywhere".
And sometimes b/c of customer requirements Boost isn't cheaper. As someone already mentioned, in the US defense industry, where C++ is used extensively, there are requirements about foreign sources that can create issues for using Boost. Each line of code needs to be inspected, etc, etc. If it's in the standard and from someone like MSFT/IBM then this has likely already been done. So that saves time and money.
maybe true - but I think that's a minority of cases. I'm struck by Ada - A good language I understand with HUGE DOD backing.- but overwhelmed by the spread of C. The latter was due in my opinion to the fact that it was much easier to port to new platforms. I'm thinking we're dismissing a real problem as something that we have no control or influence over. Modern C++ exploits newer features of C++ (i.e. templates) in such as way that it requires either highly conformant compilers and/or workarounds for each/any compiler. This slows down the development and spread of libraries. As an example take just one feature - two phase lookup. Its in the standard - but apparently not every compiler vendor is on board that its a good idea. So many libraries must effectively have two versions (defined by #if/#endif). Mix in a couple more features like this - and its can be a big hassle to get a complicated library ported from one implementation to another Now add concepts. Perhaps a worthy idea. But what about the side effects? presumably it will not be included in all implementations simultaneously and if history is any guide - it will be years -if ever- its commonly supported. This will add yet one more variable to the mix that has to be contended with to make libraries portable. My view is that the adding an interface to the "standard" and declaring implementations that don't include a corresponding implementation "non-conformant" isn't as much help in promoting C++ as it would first appear. It doesn't help the library base grow any faster. To summarize, I think some of the inate features of the language make it harder to write libraries for than other languages and this makes the language less attractive than some newer alternatives. Robert Ramey
participants (20)
-
Arkadiy Vertleyb -
Bjørn Roald -
Dave Steffen -
David Abrahams -
Douglas Gregor -
Edward Diener -
Eric Niebler -
Ian McCulloch -
Janek Kozicki -
Jeff Garland -
John Maddock -
loufoque -
Pavel Antokolsky aka Zigmar -
Peter Dimov -
Phil Nash -
Rene Rivera -
Richard Hadsell -
Robert Ramey -
Sebastian Redl -
Shams