5 Observations - My experience with the boost libraries
Over the past years, every project that I have been involved with has tried and then either abandoned boost or highly restricted its use. As a long time boost user, I can't tell you how much debate we've had about this. I want boost to succeed, grow and be successful. Its sad. As someone who has used boost from the beginning, and has taken far more than I have given, here are some of my observations. Many of the reasons don't have specifically to do with boost, but more have to do with a preference for one programming style versus another. I have identified 5 key issues about why boost was abandoned. 1) Boost uses exceptions. 2) Printf versus Iostream. 3) Dependencies. 4) Research Projects 5) Macros 1) Boost uses exceptions. This issue is best illustrated when you want to just do something as simple as converting a "string" to an "int". boost::numeric_cast throws an exception, which forces you to wrap it into a try-catch block. The seemingly trivial issue of how to handle exceptions causes endless grief. It seems that developers still prefer "C" style casts. The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required. int value = 0; try {value = boost::numeric_cast<int>("3.00");}catch (...){} versus int value = atoi("3.00"); I think the lesson is that there is no correct answer here. As most "C++" projects use some "C" libraries, you will need to be flexible in your approach to exception handling. A pure "C++" approach of try-catch blocks is not practical. As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe. Small issue, but is undoubtably a source of a huge amount of problems. 2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style. This issue has been the source of many hours of needless debate. Pure C++ developers seem to have a aversion to "printf" style arguments. As there are very few pure C++ projects (if any), I dont hear about this as much as I once did. Most C/C++ developers prefer a printf style api. Boost needs to start providing printf style api's. Boost needs to be more practical. By not also providing printf style api's, boost is not meeting the needs of developers. Iostream may be preferable for purely academic reasons, but for practical reason, "printf" is the api style that is universally adopted. Is it boosts goal to meet only the needs of a small subset of its c++ users? If that is the goal, than it needs be clearly stated as such. As most developers have adopted a combined C/C++ style of development, a pure academic C++ style syntax is not practical for every day use. Boost needs to look at what the popular api styles are and adopt them and not be so dogamtic about its style of so-called pure "C++". 3) Dependencies. Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't. What does this mean? Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't. Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all. This issue may seem trivial, but it is the cause endless hourse of grief. It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost. For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries. The way boost was developed makes this practically impossible. Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community. Currently, boost provides the best place to do that, but it needs to be honest with its users. 4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible. This is universally considered a good thing and it is always interesting to see what the best and brightest are up too. Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs. Experience proves otherwise. The practical needs of large scale active projects are in conflict. Boost is very dogmatic and encourages a particalular style of development, which is very template based. In the right hands, a heavy templated based project can work. In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design. It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear. That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly. 5) Macros. Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable. I know there are practical reasons to use them. The main reason being compiler inadequacies. However, many developers question the value of a cutting-edge template library that is full of macros. What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath? What is the practical value of a library that can only be maintained by the original developer(s)? This issue has surprised many, but has comes up often. If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries. Tom Brinkman
Tom Brinkman wrote:
I have identified 5 key issues about why boost was abandoned.
1) Boost uses exceptions.
This issue is best illustrated when you want to just do something as simple as converting a "string" to an "int". boost::numeric_cast throws an exception, which forces you to wrap it into a try-catch block.
The seemingly trivial issue of how to handle exceptions causes endless grief. It seems that developers still prefer "C" style casts.
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store. Having said that, they are often overused or too infrequently made optional. Boost.System is fairly recent (and being standardized) and bug reports against other libraries could encourage conversion to its use (or to similar techniques) to make exceptions optional.
int value = 0; try {value = boost::numeric_cast<int>("3.00");}catch (...){}
versus
int value = atoi("3.00");
I think the lesson is that there is no correct answer here.
If all you care about is best effort string-to-int conversion and zero is fine if no conversion is possible, then atoi() is better. Typically, however, one should exercise a bit more control. Whether that control requires exceptions is, in some measure, a matter of taste. strtol() and friends try to do things better, but one must carefully examine the return value, end pointer, and errno value to correctly determine whether the conversion succeeds. I usually prefer to get an exception from code that has done all of that troublesome effort unless *profiling* shows the overhead is significant.
As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe.
You are forced to wrap code that can emit exceptions only if you wish to ignore them or must translate them into error codes for some other code. Otherwise, you must face reality and properly account for the exceptions.
2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style.
Boost.Format provides what you want. There's relatively little output from the various libraries, so I don't see where this issue arises in real use cases.
Boost needs to start providing printf style api's.
As an example, Boost.Log, just up for review, provides support for Boost.Format as well as IOStreams.
Is it boosts goal to meet only the needs of a small subset of its c++ users? If that is the goal, than it needs be clearly stated as such.
Boost is clearly targeted toward advanced uses of C++ and standardization. Nevertheless, I agree that there's no reason to alienate those who like printf()-style I/O.
3) Dependencies.
Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't.
The dependencies aren't confusing so much as complex. Would you have each library in Boost reinvent rather than reuse other Boost functionality? Isn't that the point of Boost libraries: reuse functionality written by others?
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
I don't see why dependencies among Boost libraries would lead to picking and choosing which are approved.
It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost.
Ah, you actually meant that project leads wish to constrain which parts of Boost may be used but because of the inter-library dependencies, much more than wanted must be allowed.
The way boost was developed makes this practically impossible.
You're welcome to contribute patches where you think such dependencies can be reduced.
Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community.
I don't think Boost "pretends" to be much more than that. Many understand that there are no guarantees as to performance, compatibility, etc. among Boost libraries.
4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible.
This is universally considered a good thing and it is always interesting to see what the best and brightest are up too.
Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs.
Boost aims to be a proving ground for practical research, frequently en route to standardization, with the intention of solving real needs. It has never pretended to be a collection of libraries to be used where long term maintenance and stability are important.
Boost is very dogmatic and encourages a particalular style of development, which is very template based.
Boost is not dogmatic about whether a library uses templates. It just happens that a lot of problems can be solved really nicely using templates and they are interesting to the volunteers who submit libraries.
In the right hands, a heavy templated based project can work.
In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design.
Why should you care about that? If you can't stomach an unstable library, don't use it until it has baked a while.
It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear.
I find template code to be a pain when things don't go right, but a real boon when they do. I use templates, whether my own or from libraries such as in Boost, within my code to support others. I control how much template code is exposed to others.
That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly.
Hmmm, that means that template-based code is a good thing. Perhaps you can be more specific about your problems and avoid generalities.
5) Macros.
Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable.
I know there are practical reasons to use them.
The main reason being compiler inadequacies.
However, many developers question the value of a cutting-edge template library that is full of macros.
That simply points to the ignorance of those developers then. Boost is multi-platform and must account for myriad differences. Yes, this is in large part because Boost tries to push the envelope, but just have a look at the source for GCC and other portable projects. Boost isn't alone in such macro-controlled configuration and workaround code.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Write once code is easy to create, of course, but if you can't grok what's in a Boost library, then don't bother. Treat it like a black box.
What is the practical value of a library that can only be maintained by the original developer(s)?
You write to the interface and if the library provides useful functionality, you're golden!
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
I don't understand why a library is "very dangerous to use" if you can't understand its implementation. That just suggests that you want Boost to be dumbed down for some arbitrarily low experience level. I understand that template heavy code is a real burden for many to understand and use. Templates are an entirely different language within C++ (and they can be used to create still others -- DSELs). Some don't care to learn that language. Fine. Why should Boost avoid them to satisfy those that don't care to learn templates that well? There are certainly things that can be done to make Boost more accessible to more people. I'm sure all library authors will welcome constructive input from you and others with your concerns. (I expect patches will be still more welcome.) I hope that you review all submitted libraries and make comments on how they can be simplified, how template usage can be reduced, etc., in order to try to steer future Boost libraries along the course you prefer. Discussion is always helpful to hone designs and interfaces. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Zitat von "Stewart, Robert" <Robert.Stewart@sig.com>:
Tom Brinkman wrote:
I have identified 5 key issues about why boost was abandoned.
1) Boost uses exceptions.
there are measures taken where it makes sense to support exceptions and error codes, e.g. in Boost.FileSystem. which libraries should support error codes that currently don't? I don't think lexical_cast is a valid example. lexical_cast is neither efficient nor flexible, it is a simple tool.
3) Dependencies.
The dependencies aren't confusing so much as complex. Would you have each library in Boost reinvent rather than reuse other Boost functionality? Isn't that the point of Boost libraries: reuse functionality written by others?
I don't think the dependency itself is the problem (if it is the result of reused funtionality), but that dependencies are hardly documented anywhere. boost could publish a dependency graph that lets you easily figure out "if I use libraries A, B and C, I can delete all boost directories except X,Y,Z". and make it a requirement for reviewed documentation to state its dependencies.
5) Macros.
Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable.
a lot of the macro'ed code of boost that is really unreadable I think is due to the lack of variadic template parameters. certainly MPL.
The main reason being compiler inadequacies.
that's just reality, and not related to the fact that boost "pushes the envelope". boost has been around for a while and still has code working around MSVC 6 bugs.
There are certainly things that can be done to make Boost more accessible to more people. I'm sure all library authors will welcome constructive input from you and others with your concerns. (I expect patches will be still more welcome.)
this is unfortunately not my experience, that input or even patches are welcome. I understand why that is the case, people got stuff to do. but he has a point in that a boost library only has one maintainer and isn't really a joint effort like other open source projects, even when it is accepted into the official distribution. this interacts with the fact that it is hard to contribute to boost other than submitting a complete library. (see GSoC discussion)
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new. In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this. One of the first thing that comes up when a mixed language C/C++ project uses a C++ library is: Does this library throw exceptions? Generally and unfortunately, if the answer is yes, that library will be ignored out of hand.
2) Printf versus Iostream. Most developers still prefer "printf" over
"iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style.
Boost.Format provides what you want. There's relatively little output from the various libraries, so I don't see where this issue arises in real use cases.
This is a real issue. Boost.format is not a replacement for Printf -- they have different syntaxes. Printf style arguments are the prevailing api style. No one is asking for printf style arguments to be replaced. Why replace something that is the standard and works just fine. This is just symptomatic of my larger point that boost is a research project and not relevent to day to day C/C++ programmers. Why replace something that is universally adopted and works just fine. If boost developers want to create an alternative to printf, that is fine. However, it should be just that, an alternative, not a replacement. Printf style api's are easy to implement. There are reasons not to do them.
3) Dependencies.
Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't.
The dependencies aren't confusing so much as complex. Would you have each library in Boost reinvent rather than reuse other Boost functionality? Isn't that the point of Boost libraries: reuse functionality written by others?
It can absolutely be an issue if one of the dependent libraries throws exceptions for example. Because boost does not have clearly stated policy about exceptions, who knows what changes occured between versions.
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
I don't see why dependencies among Boost libraries would lead to picking and choosing which are approved.
This is a key issue. Because boost does not allow you to choose only select libraries, you must use all of boost. And because there are no clear guidlines regarding exceptions and policies, it can be scarey to know what exactly is going on. Project prefer safety to features. If the risks of using boost are unclear without is clear policies about exceptions and depencies, its easier to not use boost at all so its abandoned in its entirety, no matter how much you want to use a specific library.
----- Original Message ----- From: "Tom Brinkman" <reportbase2007@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, March 23, 2010 10:43 PM Subject: Re: [boost] 5 Observations - My experience with the boost libraries
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new.
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
One of the first thing that comes up when a mixed language C/C++ project uses a C++ library is: Does this library throw exceptions?
Generally and unfortunately, if the answer is yes, that library will be ignored out of hand.
Why?
2) Printf versus Iostream. Most developers still prefer "printf" over
"iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style.
Boost.Format provides what you want. There's relatively little output from the various libraries, so I don't see where this issue arises in real use cases.
This is a real issue.
Boost.format is not a replacement for Printf -- they have different syntaxes.
Printf style arguments are the prevailing api style. No one is asking for printf style arguments to be replaced. Why replace something that is the standard and works just fine.
No body forbids you to use printf.
This is just symptomatic of my larger point that boost is a research project and not relevent to day to day C/C++ programmers. Why replace something that is universally adopted and works just fine.
Just don't use it if you don't like it.
If boost developers want to create an alternative to printf, that is fine. However, it should be just that, an alternative, not a replacement.
It is not a replacement but an alternative.
Printf style api's are easy to implement. There are reasons not to do them.
Have you some examples of Boost library API that should provide a printf like function?
3) Dependencies.
Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't.
The dependencies aren't confusing so much as complex. Would you have each library in Boost reinvent rather than reuse other Boost functionality? Isn't that the point of Boost libraries: reuse functionality written by others?
It can absolutely be an issue if one of the dependent libraries throws exceptions for example. Because boost does not have clearly stated policy about exceptions, who knows what changes occured between versions.
Could you propose an alternative that solve this issue?
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
I don't see why dependencies among Boost libraries would lead to picking and choosing which are approved.
This is a key issue. Because boost does not allow you to choose only select libraries, you must use all of boost.
Ther is bcp.
And because there are no clear guidlines regarding exceptions and policies, it can be scarey to know what exactly is going on.
Please make a proposal.
Project prefer safety to features. If the risks of using boost are unclear without is clear policies about exceptions and depencies, its easier to not use boost at all so its abandoned in its entirety, no matter how much you want to use a specific library.
It is a shame people abandon Boost without trying before to improve it. Best, Vicente
On Tue, Mar 23, 2010 at 2:43 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
Look at the design of C++ constructors: the postcondition of a constructor is that the object instance is initialized successfully. Had Stroustrup listened to people arguing about "optional" exception handling, the C++ constructors would have been useless because they wouldn't have that postcondition. It is the same with any other use of exceptions. Make them optional, and you throw away the *only* reason to use them in the first place: to enforce postconditions. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Sometimes it feels like Linus has a lot of aliases on these lists ;-) I especially liked the - partly retracted, admittedly - statement that C++ developers have a lot to learn from the typical C developer, but probably not the other way around. Especially in the light of the typical C++ developer often having been a typical C developer 7 years earlier. And most master C++ developers having been typical C developers 14-22 years ago. The only point with which I agree is those ugly macros. Yes, I know why we need them, but they are still ugly. BUT, PP is a splendid engineering effort (in retrofitting the C++ preprocessor for tasks it was not meant to handle.) Boost is the only set of libraries in a "conventional" language that do as I think, which is why it is good :-) /David On Mar 23, 2010, at 6:48 PM, Emil Dotchevski wrote:
On Tue, Mar 23, 2010 at 2:43 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
Look at the design of C++ constructors: the postcondition of a constructor is that the object instance is initialized successfully. Had Stroustrup listened to people arguing about "optional" exception handling, the C++ constructors would have been useless because they wouldn't have that postcondition.
It is the same with any other use of exceptions. Make them optional, and you throw away the *only* reason to use them in the first place: to enforce postconditions.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Those of us that started out learning C++ before ever learning C, have had to do lots of backfilling. By learning C, what I mean is getting really good at pointer manipulations and managing memory yourself. C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer. Sorry to say, but as a graphics programer, C++ is practically useless. Its all C. However, I'm originally a C++ developer, and i'm still a boost/C++ supporter. For Boost to remain relevent, it needs to reflect the reality of modern development. That is most projects are mixed C/C++ projects. The needs of both communities need to be met. Because boost only meets the needs of C++ developers, it will continue to loose relevance. I'm just saying what people are thinking. On Tue, Mar 23, 2010 at 4:03 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
Sometimes it feels like Linus has a lot of aliases on these lists ;-)
I especially liked the - partly retracted, admittedly - statement that C++ developers have a lot to learn from the typical C developer, but probably not the other way around. Especially in the light of the typical C++ developer often having been a typical C developer 7 years earlier. And most master C++ developers having been typical C developers 14-22 years ago.
The only point with which I agree is those ugly macros. Yes, I know why we need them, but they are still ugly. BUT, PP is a splendid engineering effort (in retrofitting the C++ preprocessor for tasks it was not meant to handle.)
Boost is the only set of libraries in a "conventional" language that do as I think, which is why it is good :-)
/David
On Mar 23, 2010, at 6:48 PM, Emil Dotchevski wrote:
In any event, my point is that c++ exception handeling should be
On Tue, Mar 23, 2010 at 2:43 PM, Tom Brinkman <reportbase2007@gmail.com> wrote: optional.
Boost libraries need to be updated to reflect this.
Look at the design of C++ constructors: the postcondition of a constructor is that the object instance is initialized successfully. Had Stroustrup listened to people arguing about "optional" exception handling, the C++ constructors would have been useless because they wouldn't have that postcondition.
It is the same with any other use of exceptions. Make them optional, and you throw away the *only* reason to use them in the first place: to enforce postconditions.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 23, 2010 at 5:21 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
Seems to be the opposite of reality.
I'm just saying what people are thinking.
You're just trolling, actually. I only know 2 C curmudgeons that thinks what you have asserted. Jon
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion. Sure there are C++ wrappers around the C libraries that do the acceleration, so you are loosly correct. But the actual graphics code is all done in C.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
Seems to be the opposite of reality.
My larger point is we C++ developers, have the unique advantage of being able to use C as well. Why not take advantage of that. There is alot of good work being done ine C world. Check it out.
Trolling?
Come on. Is that what you say when you have a disagreement with someone. Not fair on your part. On Tue, Mar 23, 2010 at 4:28 PM, Jonathan Franklin < franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 5:21 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
Seems to be the opposite of reality.
I'm just saying what people are thinking.
You're just trolling, actually. I only know 2 C curmudgeons that thinks what you have asserted.
Jon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion.
I never understood this idea that some libraries were not possible to build in C++. And, specifically, what graphics hardware acceleration has to do with C++(-specific) constructs. Are there intrinsic inefficiencies of C++ constructs (beside one indirection by virtual functions where they are used)? Is it something else? Yes, most low-level API's require a pointer to a memory area in the end, but does that force us to constantly send that raw pointer around? /David
On Tue, Mar 23, 2010 at 4:54 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion.
I never understood this idea that some libraries were not possible to build in C++?
If you're looking for something that makes C++ worse than C for graphics programming, you won't find it simply because C++ is a superset of C. Anything you can do in C you can do in C++ too. I believe what Tom means is that the graphics interfaces typical C++ programmers design are not as good as graphics interfaces designed by C programmers. From that point of view, C++ programmers do have a lot to learn from C programmers. There is nothing more encapsulating and more abstract than a basic C interface: struct foo; foo * create_foo( ..... ); void frobnicate( foo * ); void destroy_foo( foo * ); For such interfaces, the most important thing is to physically decouple the user from implementation details. Templates and classes are useless for that. There are only two benefits of using C++ even for such C-style interfaces: 1) Use exceptions to report errors. 2) Use shared_ptr instead of relying on users to call destroy. The latter is not too important because even the pure C interface can easily be wrapped in a shared_ptr by the user. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
If you're looking for something that makes C++ worse than C for graphics programming, you won't find it simply because C++ is a superset of C. Anything you can do in C you can do in C++ too.
Exactly right. Thanks for rewording that for me.
There are only two benefits of using C++ even for such C-style interfaces:
1) Use exceptions to report errors. 2) Use shared_ptr instead of relying on users to call destroy.
The latter is not too important because even the pure C interface can easily be wrapped in a shared_ptr by the user.
Agreed. On Tue, Mar 23, 2010 at 5:07 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Tue, Mar 23, 2010 at 4:54 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion.
I never understood this idea that some libraries were not possible to build in C++?
If you're looking for something that makes C++ worse than C for graphics programming, you won't find it simply because C++ is a superset of C. Anything you can do in C you can do in C++ too.
I believe what Tom means is that the graphics interfaces typical C++ programmers design are not as good as graphics interfaces designed by C programmers. From that point of view, C++ programmers do have a lot to learn from C programmers. There is nothing more encapsulating and more abstract than a basic C interface:
struct foo; foo * create_foo( ..... ); void frobnicate( foo * ); void destroy_foo( foo * );
For such interfaces, the most important thing is to physically decouple the user from implementation details. Templates and classes are useless for that.
There are only two benefits of using C++ even for such C-style interfaces:
1) Use exceptions to report errors.
2) Use shared_ptr instead of relying on users to call destroy.
The latter is not too important because even the pure C interface can easily be wrapped in a shared_ptr by the user.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Emil Dotchevski a écrit :
There is nothing more encapsulating and more abstract than a basic C interface:
struct foo; foo * create_foo( ..... ); void frobnicate( foo * ); void destroy_foo( foo * );
For such interfaces, the most important thing is to physically decouple the user from implementation details. Templates and classes are useless for that.
There are only two benefits of using C++ even for such C-style interfaces:
1) Use exceptions to report errors.
2) Use shared_ptr instead of relying on users to call destroy.
Or better yet, use destructors...
On 03/23/2010 07:54 PM, David Bergman wrote:
I never understood this idea that some libraries were not possible to build in C++. And, specifically, what graphics hardware acceleration has to do with C++(-specific) constructs. Are there intrinsic inefficiencies of C++ constructs (beside one indirection by virtual functions where they are used)? Is it something else? Yes, most low-level API's require a pointer to a memory area in the end, but does that force us to constantly send that raw pointer around?
You are quite right. I'm working myself on a library that uses CUDA for GPU-accelerated computation, and we make *heavy* use of C++. Can we please put that old myth to rest that high-performance code needs to be done in C ? Thank you. Stefan -- ...ich hab' noch einen Koffer in Berlin...
I'd be curious to know more about what your talking about. Do you have a link or something that could illustrate a C++ graphics library that uses boost style functors and other modern C++ techniques. I was the review manager of boost::gil so i'm familiar with the best C++ effort yet. However, Gil is designed to be a wrapper around other libraries graphics libraries, which all to my knowlege have C style interfaces. However, GIL is just that a wrapper and a very good one at that. I use it regulary and have given large presentations about it. On Tue, Mar 23, 2010 at 5:08 PM, Stefan Seefeld <seefeld@sympatico.ca>wrote:
On 03/23/2010 07:54 PM, David Bergman wrote:
I never understood this idea that some libraries were not possible to build in C++. And, specifically, what graphics hardware acceleration has to do with C++(-specific) constructs. Are there intrinsic inefficiencies of C++ constructs (beside one indirection by virtual functions where they are used)? Is it something else? Yes, most low-level API's require a pointer to a memory area in the end, but does that force us to constantly send that raw pointer around?
You are quite right. I'm working myself on a library that uses CUDA for GPU-accelerated computation, and we make *heavy* use of C++.
Can we please put that old myth to rest that high-performance code needs to be done in C ?
Thank you.
Stefan --
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/23/2010 09:11 PM, Tom Brinkman wrote:
I'd be curious to know more about what your talking about. Do you have a link or something that could illustrate a C++ graphics library that uses boost style functors and other modern C++ techniques.
I was mentioning GPU-acceleration, but not in the context of "graphics library", but rather HPC code (specifically, signal- and image processing: Sourcery VSIPL++ (http://www.codesourcery.com/vsiplplusplus/) It uses expression templates heavily, and makes use of metaprogramming, for example to determine optimal implementations for operations, depending on data types, size, and alignment. An example of a domain where C++ can outperform the equivalent C API is where it can fuse expression evaluation, something that is much harder to do in C, where the compiler doesn't have the luxury of a strong type system, and thus can't quite as easily optimize away temporaries, or do compile-time dispatching. Stefan -- ...ich hab' noch einen Koffer in Berlin...
Thanks. I took a quick at at this library's requirements. The vsiplplusplus library uses IPP and MKL, which are both just "C" libraries that wrap the low level hardware intrinsics necessary to create accelerated graphics code. Still just plain "C" though. I know this because I've worked with the IPP guys. vsiplplusplus appears to be just like every other C++ graphics library, in that it just puts a pretty C++ face onto an otherwise ugly C graphics library. On Tue, Mar 23, 2010 at 6:22 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
On 03/23/2010 09:11 PM, Tom Brinkman wrote:
I'd be curious to know more about what your talking about. Do you have a link or something that could illustrate a C++ graphics library that uses boost style functors and other modern C++ techniques.
I was mentioning GPU-acceleration, but not in the context of "graphics library", but rather HPC code (specifically, signal- and image processing: Sourcery VSIPL++ (http://www.codesourcery.com/vsiplplusplus/)
It uses expression templates heavily, and makes use of metaprogramming, for example to determine optimal implementations for operations, depending on data types, size, and alignment.
An example of a domain where C++ can outperform the equivalent C API is where it can fuse expression evaluation, something that is much harder to do in C, where the compiler doesn't have the luxury of a strong type system, and thus can't quite as easily optimize away temporaries, or do compile-time dispatching.
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/23/2010 10:52 PM, Tom Brinkman wrote:
Thanks.
I took a quick at at this library's requirements.
The vsiplplusplus library uses IPP and MKL, which are both just "C" libraries that wrap the low level hardware intrinsics necessary to create accelerated graphics code. Still just plain "C" though. I know this because I've worked with the IPP guys.
vsiplplusplus appears to be just like every other C++ graphics library, in that it just puts a pretty C++ face onto an otherwise ugly C graphics library.
I have said it once, and I'm saying it again: Sourcery VSIPL++ is not a "graphics library". Your description above is not only inaccurate, it is plain wrong. You seem to be blinded by your own unsubstantiated believes. Please take this "C++ is bad" nonsense elsewhere. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
plain wrong.
So what your saying is that I read the requirents page incorrectly and that this library does not in fact use IPP and MKL? What part of what I said is incorrect? Is what your saying that the hardware accelerated code in this library in fact written using modern C++ techniques? According to the requirements page, it does not appear to. If I have misread the requirements page, please explain in detail, rather than your STUPID RANT. On Tue, Mar 23, 2010 at 8:04 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
On 03/23/2010 10:52 PM, Tom Brinkman wrote:
Thanks.
I took a quick at at this library's requirements.
The vsiplplusplus library uses IPP and MKL, which are both just "C" libraries that wrap the low level hardware intrinsics necessary to create accelerated graphics code. Still just plain "C" though. I know this because I've worked with the IPP guys.
vsiplplusplus appears to be just like every other C++ graphics library, in that it just puts a pretty C++ face onto an otherwise ugly C graphics library.
I have said it once, and I'm saying it again: Sourcery VSIPL++ is not a "graphics library". Your description above is not only inaccurate, it is plain wrong. You seem to be blinded by your own unsubstantiated believes.
Please take this "C++ is bad" nonsense elsewhere.
Thanks, Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 23, 2010 at 8:52 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
... Still just plain "C" though. I know this because I've worked with the IPP guys.
vsiplplusplus appears to be just like every other C++ graphics library, in that it just puts a pretty C++ face onto an otherwise ugly C graphics library.
I have no comment about any of the specific libraries in question. However, your argument is basically akin to asserting that the linux kernel is just a pretty C face onto an otherwise ugly assembler library, because we all know that the core parts are written in hand-optimised assembler, because compiled C just doesn't cut it. ;-) It is also troll bait, that belongs in /dev/null. The C++ wrappers to graphics libraries exist because most OS primitives and device drivers are in C, and the primitive libraries happen to be unusable for anything large scale. But that's an opinion. Let's get back to improving boost! :-) Jon
I'm tired of this thread too. But dear Johathan, you have completely missed my point. All I'm saying is that in the real world, most projects are mixed C/C++ and that the needs of both communities need to be addressed if boost is going to remain relevent. On Tue, Mar 23, 2010 at 8:09 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 8:52 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
... Still just plain "C" though. I know this because I've worked with the IPP guys.
vsiplplusplus appears to be just like every other C++ graphics library, in that it just puts a pretty C++ face onto an otherwise ugly C graphics library.
I have no comment about any of the specific libraries in question. However, your argument is basically akin to asserting that the linux kernel is just a pretty C face onto an otherwise ugly assembler library, because we all know that the core parts are written in hand-optimised assembler, because compiled C just doesn't cut it. ;-)
It is also troll bait, that belongs in /dev/null.
The C++ wrappers to graphics libraries exist because most OS primitives and device drivers are in C, and the primitive libraries happen to be unusable for anything large scale. But that's an opinion.
Let's get back to improving boost! :-)
Jon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mar 23, 2010, at 11:31 PM, Tom Brinkman wrote:
I'm tired of this thread too. But dear Johathan, you have completely missed my point. All I'm saying is that in the real world, most projects are mixed C/C++ and that the needs of both communities need to be addressed if boost is going to remain relevent.
What changes would we need to make to Boost in order to stay relevant (to that C/C++ mixed reality)? Would it require us to provide C wrappers for all our libraries? /David
On Tue, Mar 23, 2010 at 8:09 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 8:52 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
... Still just plain "C" though. I know this because I've worked with the IPP guys.
vsiplplusplus appears to be just like every other C++ graphics library, in that it just puts a pretty C++ face onto an otherwise ugly C graphics library.
I have no comment about any of the specific libraries in question. However, your argument is basically akin to asserting that the linux kernel is just a pretty C face onto an otherwise ugly assembler library, because we all know that the core parts are written in hand-optimised assembler, because compiled C just doesn't cut it. ;-)
It is also troll bait, that belongs in /dev/null.
The C++ wrappers to graphics libraries exist because most OS primitives and device drivers are in C, and the primitive libraries happen to be unusable for anything large scale. But that's an opinion.
Let's get back to improving boost! :-)
Jon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 23, 2010 at 9:35 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
What changes would we need to make to Boost in order to stay relevant (to that C/C++ mixed reality)? Would it require us to provide C wrappers for all our libraries?
My hunch is that the C wrappers are really only useful for exporting boost functionality to other languages. IME, it's usually the lowest level pieces that are written in C (or asm), and get aggregated into a C++ compilation unit. I would be curious to know if there are current use cases for importing boost into C compilation units. Anyone? Jon
On Mar 23, 2010, at 11:53 PM, Jonathan Franklin wrote:
On Tue, Mar 23, 2010 at 9:35 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
What changes would we need to make to Boost in order to stay relevant (to that C/C++ mixed reality)? Would it require us to provide C wrappers for all our libraries?
My hunch is that the C wrappers are really only useful for exporting boost functionality to other languages. IME, it's usually the lowest level pieces that are written in C (or asm), and get aggregated into a C++ compilation unit.
I would be curious to know if there are current use cases for importing boost into C compilation units. Anyone?
We are getting closer to the crux of all this... Tom has to explain if he wants Boost to: 1. still provide C++ interfaces, and thus only usable from C++ compilation units, but make those interfaces - or perhaps wrappers of existing interfaces - a bit less modern, to accommodate the lower C++ skill levels of developers in that C/C++ mix (that he talks about); or 2. provide C interfaces so separate compilation units can link with C units. Which is it? /David
We are getting closer to the crux of all this...
Good questions. Since I put myself on the line here and started this controversial thread, let me see if I can come up with some examples from my own experience. Like Emil said there may not be any real actionable items here. However, contrary to what Johanthon says, I do feel that the views I have expressed represent a sufficiently large number of developers and that they are correctly expressed on this forum. On Tue, Mar 23, 2010 at 9:05 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 11:53 PM, Jonathan Franklin wrote:
On Tue, Mar 23, 2010 at 9:35 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
What changes would we need to make to Boost in order to stay relevant (to that C/C++ mixed reality)? Would it require us to provide C wrappers for all our libraries?
My hunch is that the C wrappers are really only useful for exporting boost functionality to other languages. IME, it's usually the lowest level pieces that are written in C (or asm), and get aggregated into a C++ compilation unit.
I would be curious to know if there are current use cases for importing boost into C compilation units. Anyone?
We are getting closer to the crux of all this...
Tom has to explain if he wants Boost to:
1. still provide C++ interfaces, and thus only usable from C++ compilation units, but make those interfaces - or perhaps wrappers of existing interfaces - a bit less modern, to accommodate the lower C++ skill levels of developers in that C/C++ mix (that he talks about); or
2. provide C interfaces so separate compilation units can link with C units.
Which is it?
/David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 23, 2010 at 9:31 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
... All I'm saying is that in the real world, most projects are mixed C/C++ and that the needs of both communities need to be addressed if boost is going to remain relevent.
For the sake of not arguing, let's assume that your assertion is true. Let's hear your *actionable* proposal for improving boost. E.g. show us the better interface for <insert specific boost example here>. We *will* listen. If it's truly a better way, you *will* win support. Obviously, not from everyone, but that's okay. Jon
On Tue, Mar 23, 2010 at 8:40 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 9:31 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
... All I'm saying is that in the real world, most projects are mixed C/C++ and that the needs of both communities need to be addressed if boost is going to remain relevent.
For the sake of not arguing, let's assume that your assertion is true. Let's hear your *actionable* proposal for improving boost. E.g. show us the better interface for <insert specific boost example here>.
Tom's observations are just that, observations. In my experience, they are correct. It doesn't mean that actionable proposals are practical or possible. Frankly, I couldn't care less if a particular team uses Boost or not, unless I am writing code that they use. And then I keep my fingers crossed that I will be able to use shared_ptr at least. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Mar 23, 2010 at 10:06 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
Tom's observations are just that, observations. In my experience, they are correct. It doesn't mean that actionable proposals are practical or possible.
My experience turns out to be quite different. And that's fine. No single person represents the entire boost, let alone C/C++ developer community. If no one has anything further to add that will actually benefit boost, then this thread should be ruthlessly abandoned. But thanks for sharing. ;-) And seriously, anyone who just wants to sound off their opinions about C++ in general, or anything non-boost-related for that matter, should find a more appropriate forum.
Frankly, I couldn't care less if a particular team uses Boost or not, unless I am writing code that they use. And then I keep my fingers crossed that I will be able to use shared_ptr at least. :)
I only care because wide-spread adoption of boost (in whole or parts) makes my job of convincing program managers to allow me to use boost a *lot* easier. Jon
Jonathan Franklin wrote:
On Tue, Mar 23, 2010 at 10:06 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
Tom's observations are just that, observations. In my experience, they are correct. It doesn't mean that actionable proposals are practical or possible.
My experience turns out to be quite different. And that's fine. No single person represents the entire boost, let alone C/C++ developer community.
If no one has anything further to add that will actually benefit boost, then this thread should be ruthlessly abandoned. But thanks for sharing. ;-)
I think there is one thing. Tom charactarizes Libraries such as GIL or the aforementioned VSIPL++ as "just" a wrapper around C code. While in a certain sense this is true, IMVHO this also misses the point that Jonathan also raises, i.e. The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days. That means that you use them when you have to, but wrap these code parts aggressively. Now to get the curve back to boost: I think that boosts great advantage is that it can help to develop *portable* wrappers of this kind. GIL is a great example btw, if I want to develop a wrapper around some OpenGL functionality I can use GIL as an abstraction for e.g. textures. I could of course develop my own abstraction (and have, too - but it would never get as good as a boost gil is) but I couldn't expect anyone outside my sphere of influence to use it. This is gets more important the higher I want to raise the abstraction, because there are more smaller abstractions I have to use (e.g. any, variant, shared_ptr, or ...) This is also why I disagree with point 3 of Toms observations, because IMVHO it is a great boon to know that I have *all* the small boost tools at my disposal, and that it becomes fairly automatic that programmers use the boost version instead of rolling their own, or even go hunting for something else. Regards, Fabio
All valid points. I like Gil as well. Unfortunately, it hasnt been updatted or enhanced in a long time. (correctly if I'm wrong) Not saying that it needs to be. Its pretty solid. This unfortunately kinda relates to alot of the other points made here this morning Who owns GIL now? Does boost? Can we change it without talking to the adobe developers. Do we need to consult with them? I would say no, but thats my opinion. As I see it, the boost community now owns the code, and can modify as the community sees fit. See Johnothan's library. He should be able to add his enhacements with only mild consideration from the original developers. On Wed, Mar 24, 2010 at 2:17 PM, Fabio Fracassi <f.fracassi@gmx.net> wrote:
Jonathan Franklin wrote:
On Tue, Mar 23, 2010 at 10:06 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
Tom's observations are just that, observations. In my experience, they are correct. It doesn't mean that actionable proposals are practical or possible.
My experience turns out to be quite different. And that's fine. No single person represents the entire boost, let alone C/C++ developer community.
If no one has anything further to add that will actually benefit boost, then this thread should be ruthlessly abandoned. But thanks for sharing. ;-)
I think there is one thing. Tom charactarizes Libraries such as GIL or the aforementioned VSIPL++ as "just" a wrapper around C code. While in a certain sense this is true, IMVHO this also misses the point that Jonathan also raises, i.e. The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days. That means that you use them when you have to, but wrap these code parts aggressively.
Now to get the curve back to boost: I think that boosts great advantage is that it can help to develop *portable* wrappers of this kind. GIL is a great example btw, if I want to develop a wrapper around some OpenGL functionality I can use GIL as an abstraction for e.g. textures. I could of course develop my own abstraction (and have, too - but it would never get as good as a boost gil is) but I couldn't expect anyone outside my sphere of influence to use it.
This is gets more important the higher I want to raise the abstraction, because there are more smaller abstractions I have to use (e.g. any, variant, shared_ptr, or ...) This is also why I disagree with point 3 of Toms observations, because IMVHO it is a great boon to know that I have *all* the small boost tools at my disposal, and that it becomes fairly automatic that programmers use the boost version instead of rolling their own, or even go hunting for something else.
Regards,
Fabio
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Tom, On 3/24/10 2:38 PM, "Tom Brinkman" <reportbase2007@gmail.com> wrote:
All valid points.
I like Gil as well.
Unfortunately, it hasnt been updatted or enhanced in a long time. (correctly if I'm wrong) Not saying that it needs to be. Its pretty solid.
This unfortunately kinda relates to alot of the other points made here this morning Who owns GIL now? Does boost? Can we change it without talking to the adobe developers. Do we need to consult with them?
Unfortunately I have been spending very little of my time over the past couple of years with GIL while I am doing my Ph.D. but I plan to increase my involvement as I finish my Ph.D. I am hoping that (if we did our job right) no major future changes to GIL core will be necessary. It would be best if we (Hailin, Christian and I) maintain ownership of GIL core and future changes happen through us, unless they are minor compile fixes. That said, there is a lot more to be done with GIL, but I see future work as adding/replacing GIL extensions. Christian is working on an overhaul of gil::io. What we need is extensions to do image processing algorithms, such as high-quality fast resampling and convolution, morphological operations, extending GIL to video, adding support for intrinsics, adding vector graphics and type support, GIL-ifying VIGRA, adding good OpenCV wrapper, etc. I have heard some people express interest in doing some of these items, and there are some extensions available already, but nothing is proposed to Boost. We can't expect the original authors to do all future extensions. Isn't one of the strengths of open source that people jump in and contribute? I am a bit disappointed that this is not happening, or is happening very slowly. Tom, you have done some great GIL extensions that deal with vector graphics and type; have you thought about proposing them for inclusion into Boost? What prevents you and others from contributing? Lubomir
Glad to hear your PHD is going well. Since we last talked, i've gotten pretty good at poking through the GIL source code. Still impresses me. I've learned alot about advanced template usage just by looking at how GIL does it. Its a very readable style -- that even I can figure out. I've completely converted two entire codebases over to use GIL and I still only use a subset of GIL's funtionality. Yeah, I've got code lots of code that extends GIL. I've been waiting to let anyone use it, because, I change it so often. The best feature about GIl is all the typedefs of the various buffer packings. Wow, does that make things easier. I also love "view" concept. It works beatifully. Much bettern than just your standard "ROI" range of interest, that every one seems to use. When ever you want I could shoot you over what I got. Best regards, Tom Brinkman On Fri, Mar 26, 2010 at 12:47 AM, Lubomir Bourdev <lbourdev@adobe.com> wrote:
Hi Tom,
On 3/24/10 2:38 PM, "Tom Brinkman" <reportbase2007@gmail.com> wrote:
All valid points.
I like Gil as well.
Unfortunately, it hasnt been updatted or enhanced in a long time. (correctly if I'm wrong) Not saying that it needs to be. Its pretty solid.
This unfortunately kinda relates to alot of the other points made here this morning Who owns GIL now? Does boost? Can we change it without talking to the adobe developers. Do we need to consult with them?
Unfortunately I have been spending very little of my time over the past couple of years with GIL while I am doing my Ph.D. but I plan to increase my involvement as I finish my Ph.D.
I am hoping that (if we did our job right) no major future changes to GIL core will be necessary. It would be best if we (Hailin, Christian and I) maintain ownership of GIL core and future changes happen through us, unless they are minor compile fixes.
That said, there is a lot more to be done with GIL, but I see future work as adding/replacing GIL extensions. Christian is working on an overhaul of gil::io.
What we need is extensions to do image processing algorithms, such as high-quality fast resampling and convolution, morphological operations, extending GIL to video, adding support for intrinsics, adding vector graphics and type support, GIL-ifying VIGRA, adding good OpenCV wrapper, etc.
I have heard some people express interest in doing some of these items, and there are some extensions available already, but nothing is proposed to Boost. We can't expect the original authors to do all future extensions. Isn't one of the strengths of open source that people jump in and contribute? I am a bit disappointed that this is not happening, or is happening very slowly. Tom, you have done some great GIL extensions that deal with vector graphics and type; have you thought about proposing them for inclusion into Boost? What prevents you and others from contributing?
Lubomir
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom, you have done some great GIL extensions?
Yes. 1) A wrapper to Freetype for font rendering 2) A wuline drawing algorithm for antialised lines. 3) A polygon fill algorithm. Its pretty simplistic though. Just a scanline algorithm.
Vector graphics?
No
What prevents you and others from contributing?
Not sure. GIL is pretty advanced, so it has a very high-bar for learning. What I think is needed is lots of simple silly trivial examples. Similar to how spirit does it. Kinda how i learned spirit was just to compile all the samples, and slowly got familiar and comfterble with it. Also, GIL can spit some really nasty error messages. Not your fault, but can be a little scarey. On Fri, Mar 26, 2010 at 12:47 AM, Lubomir Bourdev <lbourdev@adobe.com> wrote:
Hi Tom,
On 3/24/10 2:38 PM, "Tom Brinkman" <reportbase2007@gmail.com> wrote:
All valid points.
I like Gil as well.
Unfortunately, it hasnt been updatted or enhanced in a long time. (correctly if I'm wrong) Not saying that it needs to be. Its pretty solid.
This unfortunately kinda relates to alot of the other points made here this morning Who owns GIL now? Does boost? Can we change it without talking to the adobe developers. Do we need to consult with them?
Unfortunately I have been spending very little of my time over the past couple of years with GIL while I am doing my Ph.D. but I plan to increase my involvement as I finish my Ph.D.
I am hoping that (if we did our job right) no major future changes to GIL core will be necessary. It would be best if we (Hailin, Christian and I) maintain ownership of GIL core and future changes happen through us, unless they are minor compile fixes.
That said, there is a lot more to be done with GIL, but I see future work as adding/replacing GIL extensions. Christian is working on an overhaul of gil::io.
What we need is extensions to do image processing algorithms, such as high-quality fast resampling and convolution, morphological operations, extending GIL to video, adding support for intrinsics, adding vector graphics and type support, GIL-ifying VIGRA, adding good OpenCV wrapper, etc.
I have heard some people express interest in doing some of these items, and there are some extensions available already, but nothing is proposed to Boost. We can't expect the original authors to do all future extensions. Isn't one of the strengths of open source that people jump in and contribute? I am a bit disappointed that this is not happening, or is happening very slowly. Tom, you have done some great GIL extensions that deal with vector graphics and type; have you thought about proposing them for inclusion into Boost? What prevents you and others from contributing?
Lubomir
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
What I think is needed is lots of simple silly trivial examples. Similar to how spirit does it.
Yes, this is a great idea and is on my todo list. Although the tutorial is sprinkled with examples, it is not easy to find what you need without reading through the entire documentation.
Kinda how i learned spirit was just to compile all the samples, and slowly got familiar and comfterble with it.
Also, GIL can spit some really nasty error messages. Not your fault, but can be a little scarey.
I have some thoughts about this as well. It is possible to write a script that filters this giant error output and returns a much more compact and human readable error description. For example, replace the page-long description of an 8-bit rgb view with 'rgb8_view_t', etc. It is also possible to find the common causes for the errors and print them as hints. For example, if you pass the wrong view you typically get an error at a given GIL line. One could track common errors and manually add hints for them. A more advanced system could leverage the debugging power of other developers. For example, once you figure out and fix the error, you submit the error message along with an English description of what was wrong to a server. The next time you get an error, your script can check online for the error trace and give you a list of English descriptions of common causes... This script would need to be tuned for each compiler and platform, however. But it seems like a tool that many other boost libraries could benefit from. Just a thought... Any volunteers? Lubomir
Lubomir Bourdev wrote:
Also, GIL can spit some really nasty error messages. Not your fault, but can be a little scarey.
I have some thoughts about this as well. It is possible to write a script that filters this giant error output and returns a much more compact and human readable error description. For example, replace the page-long description of an 8-bit rgb view with 'rgb8_view_t', etc.
I never really used GIL but, are those long errors possibly be changed into smaller SFINAE or static assert check so you only got a simple static_assert***FAILURE*** or a no such function message ? We had the same kind of problem in NT² and we took some time putting MPL_ASSERT or enable_if in critical code path so errors went nicer.
On 3/26/10 2:05 AM, "Joel Falcou" <joel.falcou@lri.fr> wrote:
Lubomir Bourdev wrote:
Also, GIL can spit some really nasty error messages. Not your fault, but can be a little scarey.
I have some thoughts about this as well. It is possible to write a script that filters this giant error output and returns a much more compact and human readable error description. For example, replace the page-long description of an 8-bit rgb view with 'rgb8_view_t', etc.
I never really used GIL but, are those long errors possibly be changed into smaller SFINAE or static assert check so you only got a simple static_assert***FAILURE*** or a no such function message ?
We had the same kind of problem in NT² and we took some time putting MPL_ASSERT or enable_if in critical code path so errors went nicer.
GIL uses the concept check library (enabled if you #define BOOST_GIL_USE_CONCEPT_CHECK, disabled by default). So you can try enabling this and it might help. However, we haven't been methodically placing a check for every single concept in every single place. That would make GIL a lot bigger. It also would put a significant toll on compile time. Lubomir
Lubomir Bourdev wrote:
However, we haven't been methodically placing a check for every single concept in every single place. That would make GIL a lot bigger. It also would put a significant toll on compile time.
Well msot of the time we don't use Concepts per se, we just have a few mea-functions checking for what we need to check (we have an army of has_method_xxx<Sig> meta-function for ex.). A simple MPL_ASSERT is then needed, and is far less heavy in term of compile.
The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days.
Here is were we probably disagree. "C' coding is always going to be important in graphics programming. Its always going to be around in the backround. Most will want to wrap it, though, as they always have. In the future, hardware acceleration will be even more of an issue than it has been, so stay tuned. Lots of cool stuff coming your way very soon. IMO, you should just play it loose between the two worlds, "C" and "C++". Pick and choose what works for you, but keep in eye on what the "C" guys are up to because they are doing some cool as shit. On Wed, Mar 24, 2010 at 2:17 PM, Fabio Fracassi <f.fracassi@gmx.net> wrote:
Jonathan Franklin wrote:
On Tue, Mar 23, 2010 at 10:06 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
Tom's observations are just that, observations. In my experience, they are correct. It doesn't mean that actionable proposals are practical or possible.
My experience turns out to be quite different. And that's fine. No single person represents the entire boost, let alone C/C++ developer community.
If no one has anything further to add that will actually benefit boost, then this thread should be ruthlessly abandoned. But thanks for sharing. ;-)
I think there is one thing. Tom charactarizes Libraries such as GIL or the aforementioned VSIPL++ as "just" a wrapper around C code. While in a certain sense this is true, IMVHO this also misses the point that Jonathan also raises, i.e. The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days. That means that you use them when you have to, but wrap these code parts aggressively.
Now to get the curve back to boost: I think that boosts great advantage is that it can help to develop *portable* wrappers of this kind. GIL is a great example btw, if I want to develop a wrapper around some OpenGL functionality I can use GIL as an abstraction for e.g. textures. I could of course develop my own abstraction (and have, too - but it would never get as good as a boost gil is) but I couldn't expect anyone outside my sphere of influence to use it.
This is gets more important the higher I want to raise the abstraction, because there are more smaller abstractions I have to use (e.g. any, variant, shared_ptr, or ...) This is also why I disagree with point 3 of Toms observations, because IMVHO it is a great boon to know that I have *all* the small boost tools at my disposal, and that it becomes fairly automatic that programmers use the boost version instead of rolling their own, or even go hunting for something else.
Regards,
Fabio
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/24/2010 05:43 PM, Tom Brinkman wrote:
The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days.
Here is were we probably disagree. "C' coding is always going to be important in graphics programming. Its always going to be around in the backround. Most will want to wrap it, though, as they always have.
In the future, hardware acceleration will be even more of an issue than it has been, so stay tuned. Lots of cool stuff coming your way very soon.
IMO, you should just play it loose between the two worlds, "C" and "C++". Pick and choose what works for you, but keep in eye on what the "C" guys are up to because they are doing some cool as shit.
I fully agree on the "pick and choose what works" approach. However, there is absolutely nothing special about C. Yes, it gives access to "raw pointers". But so what ? Fortran is catching up on support for parallelism. And other languages (including interpreters, runtimes) get built-in support for multi-core architectures, too. Not to speak of all the research languages that are being invented specifically to address the needs of the HPC community (or tomorrow's mainstream computers). There really isn't anything in C that deserves any special attention. Stefan -- ...ich hab' noch einen Koffer in Berlin...
I guess thats where we agree to disagree. As I've pissed all you c++ graphics programmers off, I dont want to say anymore on this thread about it. Email me privately if you want my views. On Wed, Mar 24, 2010 at 3:12 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
On 03/24/2010 05:43 PM, Tom Brinkman wrote:
The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days.
Here is were we probably disagree. "C' coding is always going to be important in graphics programming. Its always going to be around in the backround. Most will want to wrap it, though, as they always have.
In the future, hardware acceleration will be even more of an issue than it has been, so stay tuned. Lots of cool stuff coming your way very soon.
IMO, you should just play it loose between the two worlds, "C" and "C++". Pick and choose what works for you, but keep in eye on what the "C" guys are up to because they are doing some cool as shit.
I fully agree on the "pick and choose what works" approach. However, there is absolutely nothing special about C. Yes, it gives access to "raw pointers". But so what ? Fortran is catching up on support for parallelism. And other languages (including interpreters, runtimes) get built-in support for multi-core architectures, too. Not to speak of all the research languages that are being invented specifically to address the needs of the HPC community (or tomorrow's mainstream computers). There really isn't anything in C that deserves any special attention.
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 23, 2010 at 6:11 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
I'd be curious to know more about what your talking about. Do you have a link or something that could illustrate a C++ graphics library that uses boost style functors and other modern C++ techniques.
I was the review manager of boost::gil so i'm familiar with the best C++ effort yet. However, Gil is designed to be a wrapper around other libraries graphics libraries, which all to my knowlege have C style interfaces. However, GIL is just that a wrapper and a very good one at that. I use it regulary and have given large presentations about it.
Someone correct me if I'm wrong but my information is that Adobe doesn't use GIL, which I think speaks to your initial rant about people not wanting to adopt Boost libraries because of 1-5. In the case of GIL at least, I think that the "people" are plain wrong. As a library designer, I'd rather do what's right, not what "people" want. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 3/23/10 6:26 PM, "Emil Dotchevski" <emildotchevski@gmail.com> wrote:
Someone correct me if I'm wrong but my information is that Adobe doesn't use GIL, which I think speaks to your initial rant about people not wanting to adopt Boost libraries because of 1-5.
Hi Emil, We at Adobe use GIL in many projects. Off the top of my head it is used in Photoshop, Photoshop Elements, After Effects, and Premiere, and possibly other products as well. The existing graphics code is not rewritten to use GIL because that would be too much work, but a lot of the new projects/features use GIL. I am curious, where is your information coming from? Lubomir
On Fri, Mar 26, 2010 at 12:15 AM, Lubomir Bourdev <lbourdev@adobe.com> wrote:
On 3/23/10 6:26 PM, "Emil Dotchevski" <emildotchevski@gmail.com> wrote:
Someone correct me if I'm wrong but my information is that Adobe doesn't use GIL, which I think speaks to your initial rant about people not wanting to adopt Boost libraries because of 1-5.
We at Adobe use GIL in many projects. Off the top of my head it is used in Photoshop, Photoshop Elements, After Effects, and Premiere, and possibly other products as well. The existing graphics code is not rewritten to use GIL because that would be too much work, but a lot of the new projects/features use GIL.
I am curious, where is your information coming from?
From a friend who works at Adobe -- evidently he is not well informed. Anyway, in case it wasn't clear, my point was that many people don't like Boost and that's not necessarily something we should worry about too much.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
but does that force us to constantly send that raw pointer around?
Yes, and it also has to be aligned. The buffer must be carefully crafted with considerable attention to caching issues. I kid you not, but I have seen some wild stuff. I've worked on the Larabee platform, which is the next generation discrete graphics card from intel. It has a 512K buffer, which means that you will be able to simultaneously process 16 floats. When you combine this with the parallelism possibilities on the next Nahalem processor (8 cores, 16 threads), you will be able to achieve processing speeds thousands of times faster then non-hardware optimized code. Unfortunately, to take advantage of this, you will need to manage the memory yourself, which requires lots of old fashioned straight "C" style coding. On Tue, Mar 23, 2010 at 4:54 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion.
I never understood this idea that some libraries were not possible to build in C++. And, specifically, what graphics hardware acceleration has to do with C++(-specific) constructs. Are there intrinsic inefficiencies of C++ constructs (beside one indirection by virtual functions where they are used)? Is it something else? Yes, most low-level API's require a pointer to a memory area in the end, but does that force us to constantly send that raw pointer around?
/David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mar 23, 2010, at 9:22 PM, Tom Brinkman wrote:
but does that force us to constantly send that raw pointer around?
Yes, and it also has to be aligned. The buffer must be carefully crafted with considerable attention to caching issues.
I kid you not, but I have seen some wild stuff.
I've worked on the Larabee platform, which is the next generation discrete graphics card from intel. It has a 512K buffer, which means that you will be able to simultaneously process 16 floats. When you combine this with the parallelism possibilities on the next Nahalem processor (8 cores, 16 threads), you will be able to achieve processing speeds thousands of times faster then non-hardware optimized code.
Unfortunately, to take advantage of this, you will need to manage the memory yourself, which requires lots of old fashioned straight "C" style coding.
Really? One can do a lot of C++-neat things with POD's. And, just ridding the virtual table goes pretty far. As someone else pointed out, with C++ and proper meta-programming tricks, one can even achieve optimal structure alignments for differing platforms with *one* codebase, which is pretty hard to do in C. Well, this is definitely leading away from the initial problem, where you think that (at least certain) Boost libraries should have a C interface. Would be cool to get back on topic (partly my bad...) and see what libraries you want to change to a more Cish appearance and how that would look. We have heard about (s)printf, but that function already exists to a C++ developer ;-) /David
On Tue, Mar 23, 2010 at 4:54 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion.
I never understood this idea that some libraries were not possible to build in C++. And, specifically, what graphics hardware acceleration has to do with C++(-specific) constructs. Are there intrinsic inefficiencies of C++ constructs (beside one indirection by virtual functions where they are used)? Is it something else? Yes, most low-level API's require a pointer to a memory area in the end, but does that force us to constantly send that raw pointer around?
/David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 23, 2010 at 6:38 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 9:22 PM, Tom Brinkman wrote:
but does that force us to constantly send that raw pointer around?
Yes, and it also has to be aligned. The buffer must be carefully crafted with considerable attention to caching issues.
I kid you not, but I have seen some wild stuff.
I've worked on the Larabee platform, which is the next generation discrete graphics card from intel. It has a 512K buffer, which means that you will be able to simultaneously process 16 floats. When you combine this with the parallelism possibilities on the next Nahalem processor (8 cores, 16 threads), you will be able to achieve processing speeds thousands of times faster then non-hardware optimized code.
Unfortunately, to take advantage of this, you will need to manage the memory yourself, which requires lots of old fashioned straight "C" style coding.
Really? One can do a lot of C++-neat things with POD's. And, just ridding the virtual table goes pretty far.
We're talking about style of interfaces, not what language you use. Even mentioning "virtual table", even just to say "ridding it", you've lost me. :)
As someone else pointed out, with C++ and proper meta-programming tricks, one can even achieve optimal structure alignments for differing platforms with *one* codebase, which is pretty hard to do in C.
In many cases, I'd rather design a C-style interface that takes pointers to incomplete types or even void pointers. Then *maybe* if it makes sense I would use meta-programming tricks in the implementation. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 03/23/2010 09:47 PM, Emil Dotchevski wrote:
In many cases, I'd rather design a C-style interface that takes pointers to incomplete types or even void pointers. Then *maybe* if it makes sense I would use meta-programming tricks in the implementation.
I wonder how that goes together. Once you start using "pointers to incomplete types" etc., you have given up valuable (type) information, which you can not gain back "in the implementation". So what meta-programming tricks are there left to play ? Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, Mar 23, 2010 at 6:56 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
On 03/23/2010 09:47 PM, Emil Dotchevski wrote:
In many cases, I'd rather design a C-style interface that takes pointers to incomplete types or even void pointers. Then *maybe* if it makes sense I would use meta-programming tricks in the implementation.
I wonder how that goes together. Once you start using "pointers to incomplete types" etc., you have given up valuable (type) information
...and I have not paid the price for that information: physical coupling!
which you can not gain back "in the implementation". So what meta-programming tricks are there left to play ?
Pointers to incomplete types are type-safe but yes, in general, I'm talking about balancing compile-time type safety and physical coupling. The "proper" way to do this in C++ is to use abstract base classes; except that an interface defined in terms of C-style functions is more abstract than a C++ abstract base class because calling a C-style function doesn't necessarily result in a virtual function call (yet it *can* call a virtual function internally, if that makes sense.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 03/23/2010 10:45 PM, Emil Dotchevski wrote:
On Tue, Mar 23, 2010 at 6:56 PM, Stefan Seefeld<seefeld@sympatico.ca> wrote:
On 03/23/2010 09:47 PM, Emil Dotchevski wrote:
In many cases, I'd rather design a C-style interface that takes pointers to incomplete types or even void pointers. Then *maybe* if it makes sense I would use meta-programming tricks in the implementation.
I wonder how that goes together. Once you start using "pointers to incomplete types" etc., you have given up valuable (type) information
...and I have not paid the price for that information: physical coupling!
I agree. But that's now a completely separate concern. Remember we are arguing about performance and how it is impacted by the choice of language and API.
which you can not gain back "in the implementation". So what meta-programming tricks are there left to play ?
Pointers to incomplete types are type-safe but yes, in general, I'm talking about balancing compile-time type safety and physical coupling.
The "proper" way to do this in C++ is to use abstract base classes;
Sorry, no. An "abstract base class" is something specifically tied to the Object Oriented Programming paradigm, and thus, runtime binding. Meta-programming, on the other hand, is all about compile-time binding, which you can't get with abstract base classes.
except that an interface defined in terms of C-style functions is more abstract than a C++ abstract base class because calling a C-style function doesn't necessarily result in a virtual function call (yet it *can* call a virtual function internally, if that makes sense.)
You are comparing apples and oranges. If you want the kind of abstraction that abstract base classes give you, i.e. (runtime) polymorphism, you surely want to operate with some form of function pointers. And these are very similar to virtual functions. I can't believe we are having this discussion on this list... Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, Mar 23, 2010 at 7:57 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
On 03/23/2010 10:45 PM, Emil Dotchevski wrote:
On Tue, Mar 23, 2010 at 6:56 PM, Stefan Seefeld<seefeld@sympatico.ca> wrote:
which you can not gain back "in the implementation". So what meta-programming tricks are there left to play ? Pointers to incomplete types are type-safe but yes, in general, I'm talking about balancing compile-time type safety and physical coupling. The "proper" way to do this in C++ is to use abstract base classes; Sorry, no. An "abstract base class" is something specifically tied to the Object Oriented Programming paradigm, and thus, runtime binding. Meta-programming, on the other hand, is all about compile-time binding, which you can't get with abstract base classes.
Compile-time binding is invaluable tool indeed, I'm not saying that you can replace it with something else. My point is that losing some physical coupling (and sometimes, compile-time type safety) is an option that should be considered when designing any interface.
except that an interface defined in terms of C-style functions is more abstract than a C++ abstract base class because calling a C-style function doesn't necessarily result in a virtual function call (yet it *can* call a virtual function internally, if that makes sense.) You are comparing apples and oranges. If you want the kind of abstraction that abstract base classes give you, i.e. (runtime) polymorphism, you surely want to operate with some form of function pointers. And these are very similar to virtual functions.
Yes, you do need to arrive at something like a function pointer if you want to call a function dynamically. No, the virtual function dispatch defined by C++ is not the only way to do that. Secondly, in a C-style interface you don't know if a particular function is dispatched dynamically or not. This is true for virtual function interfaces too, except that if you want to change a function to non-virtual or vice versa you'll force the user code to recompile. You could use pimpl but what's the point? Just so you can write x.foo() instead of foo(x)? :)
I can't believe we are having this discussion on this list...
Yes, the discussion is sort of pointless, because it won't lead to anything useful. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Mar 23, 2010 at 7:47 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
In many cases, I'd rather design a C-style interface that takes pointers to incomplete types or even void pointers. Then *maybe* if it makes sense I would use meta-programming tricks in the implementation.
I'll take the speed and expressive power of a generic object/function framework with references over a C-style interface any day. Unless I need to interface w/ another language, in which case I'll write a C-style wrapper... For some other poor schmuck to use. I am thankful for each day that I don't have to look at a void * interface, and hope they all die a swift, but exquisitely painful death. </troll_bait> But let's see your proposed boost interface improvements. Otherwise, this is all meaningless opinion hawking, best served up on IRC or some general C++ news forum. Jon
On Tue, Mar 23, 2010 at 5:40 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
Trolling?
Come on. Is that what you say when you have a disagreement with someone. Not fair on your part.
Nope. Only when the "debate" is obvious troll-bait. This is no longer a useful thread, and IMO should be moderated into oblivion. Jon
No comment. On Tue, Mar 23, 2010 at 4:55 PM, Jonathan Franklin < franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 5:40 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
Trolling?
Come on. Is that what you say when you have a disagreement with someone. Not fair on your part.
Nope. Only when the "debate" is obvious troll-bait. This is no longer a useful thread, and IMO should be moderated into oblivion.
Jon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jonathan Franklin wrote:
On Tue, Mar 23, 2010 at 5:40 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
Trolling? Come on. Is that what you say when you have a disagreement with someone. Not fair on your part.
Nope. Only when the "debate" is obvious troll-bait. This is no longer a useful thread, and IMO should be moderated into oblivion.
Jon
Jon, I think you are being unfair here. Tom has put several years of hard work into Boost, including preceding me as a Review Wizard, where he served for a few years, and managing a few reviews. I honestly believe that he is trying to start a discussion that he hopes will help Boost. That is not the same thing as saying I agree with him. I wrote an over long post elsewhere in this thread expanding on one point where I disagree. In general, I am much more tolerant of both templates and the use of the preprocessor than Tom is. I think that is an honest difference of stylistic opinion between us, and is in no way trolling. It may be uncommon in current US society, but I find it quite easy to strongly disagree with someone on some topic that is important to me, but still like and respect that person. John
On Wed, Mar 24, 2010 at 6:54 PM, John Phillips <phillips@mps.ohio-state.edu> wrote:
I think you are being unfair here. Tom has put several years of hard work into Boost, including preceding me as a Review Wizard, where he served for a few years, and managing a few reviews. I honestly believe that he is trying to start a discussion that he hopes will help Boost.
I am aware of Tom's contributions to boost. However, his claims that C++ is useless to graphics programming, people who learn C first are better programmers, etc. are: 1. Entirely opinion. 2. Entirely off topic for this list. 3. Incite impassioned responses from the otherwise smart and well-meaning members of this list. This is classic troll bait, and has no place in this forum.
It may be uncommon in current US society, but I find it quite easy to strongly disagree with someone on some topic that is important to me, but still like and respect that person.
Please note that in claiming that these statements are troll bait, I have not made any insinuation of dislike or disrespect towards Tom. I believe the record will show that I never actually called anyone a troll. I simply pointed out the "baited" statements, and encouraged people to get back on topic. I chose not to engage in any of the inflammatory off-topic debate simply because I feel that it is the best way to get back on topic. I encourage everyone to (re-)read the following, and try to keep future discussion useful to boost: http://www.boost.org/community/policy.html Jon
I made the comparisions between C and C++ to illustrate a point. Sadly, you seem to have missed it. On Wed, Mar 24, 2010 at 6:22 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Wed, Mar 24, 2010 at 6:54 PM, John Phillips <phillips@mps.ohio-state.edu> wrote:
I think you are being unfair here. Tom has put several years of hard work into Boost, including preceding me as a Review Wizard, where he served for a few years, and managing a few reviews. I honestly believe that he is trying to start a discussion that he hopes will help Boost.
I am aware of Tom's contributions to boost. However, his claims that C++ is useless to graphics programming, people who learn C first are better programmers, etc. are: 1. Entirely opinion. 2. Entirely off topic for this list. 3. Incite impassioned responses from the otherwise smart and well-meaning members of this list.
This is classic troll bait, and has no place in this forum.
It may be uncommon in current US society, but I find it quite easy to strongly disagree with someone on some topic that is important to me, but still like and respect that person.
Please note that in claiming that these statements are troll bait, I have not made any insinuation of dislike or disrespect towards Tom. I believe the record will show that I never actually called anyone a troll. I simply pointed out the "baited" statements, and encouraged people to get back on topic. I chose not to engage in any of the inflammatory off-topic debate simply because I feel that it is the best way to get back on topic.
I encourage everyone to (re-)read the following, and try to keep future discussion useful to boost: http://www.boost.org/community/policy.html
Jon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I should have said, sadly, I didnt explain it very well. Sorry for my wording. On Wed, Mar 24, 2010 at 7:51 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
I made the comparisions between C and C++ to illustrate a point. Sadly, you seem to have missed it.
On Wed, Mar 24, 2010 at 6:22 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Wed, Mar 24, 2010 at 6:54 PM, John Phillips <phillips@mps.ohio-state.edu> wrote:
I think you are being unfair here. Tom has put several years of hard work into Boost, including preceding me as a Review Wizard, where he served for a few years, and managing a few reviews. I honestly believe that he is trying to start a discussion that he hopes will help Boost.
I am aware of Tom's contributions to boost. However, his claims that C++ is useless to graphics programming, people who learn C first are better programmers, etc. are: 1. Entirely opinion. 2. Entirely off topic for this list. 3. Incite impassioned responses from the otherwise smart and well-meaning members of this list.
This is classic troll bait, and has no place in this forum.
It may be uncommon in current US society, but I find it quite easy to strongly disagree with someone on some topic that is important to me, but still like and respect that person.
Please note that in claiming that these statements are troll bait, I have not made any insinuation of dislike or disrespect towards Tom. I believe the record will show that I never actually called anyone a troll. I simply pointed out the "baited" statements, and encouraged people to get back on topic. I chose not to engage in any of the inflammatory off-topic debate simply because I feel that it is the best way to get back on topic.
I encourage everyone to (re-)read the following, and try to keep future discussion useful to boost: http://www.boost.org/community/policy.html
Jon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Mar 24, 2010 at 8:51 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
I made the comparisions between C and C++ to illustrate a point. Sadly, you seem to have missed it.
You are clearly missing mine, so let's just kill this thread, and move on to topics that benefit boost. Thanks, Jon
Thanks John. Nice words. I have taken far more from boost than I have given. Let me just summarize my views by saying that I think that boost is at a turning point. I hear lots and lots of grumbling. Most of it is a general frustration and angst about the future. With microsoft's .Net, apples osx, and Java, C/C++ is no longer the top dog. C/C++ is just one of many different approaches to software development. Its not like it used to be. I see boost as our last great hope. Granted boost is very C++ centric. It is my mission to make boost more friendly to C projects. Why do we fight. Why are C programmers so generrally frustrated with C++ programmers. I can help there, if anyone is interested to listen. I would hope that C++ programmers would just hear us out. Make a few concessions, where its not too painful. I guess, what I see is that we C/C++ developers should get together. There is so much that we could do if we fought for each other. We argue because there is a friendly comptition between the languages, but if we were smart, we would realize that our real compition is elsewhere and we are far better off joining forces, so to speak.
Jon
Jon,
I think you are being unfair here. Tom has put several years of hard work into Boost, including preceding me as a Review Wizard, where he served for a few years, and managing a few reviews. I honestly believe that he is trying to start a discussion that he hopes will help Boost.
That is not the same thing as saying I agree with him. I wrote an over long post elsewhere in this thread expanding on one point where I disagree. In general, I am much more tolerant of both templates and the use of the preprocessor than Tom is. I think that is an honest difference of stylistic opinion between us, and is in no way trolling.
It may be uncommon in current US society, but I find it quite easy to strongly disagree with someone on some topic that is important to me, but still like and respect that person.
John
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Zitat von Tom Brinkman <reportbase2007@gmail.com>:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion. Sure there are C++ wrappers around the C libraries that do the acceleration, so you are loosly correct. But the actual graphics code is all done in C.
the (realtime) graphics/gaming industry is notorious for being among the latest adopters when it comes to platform/toolchain. some of this is well-founded because of special requirements like compile-time and efficient debug-builds, but a lot of it is also for reasons I can only speculate resemble the opinion you expressed above. if you want to help boost to better meet the requirements of that industry I'm sure you're welcome to do so. a good starting point would be to read this document by your colleagues at EA about their implementation of STL, intrusive containers and more, specifically tuned towards gaming/realtime graphics: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html it's from 2007, so it can only be another decade until your industry switches to Windows...I mean, switches to C++.
Zitat von Tom Brinkman <reportbase2007@gmail.com>:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. Sure, we use C++ around the edges. The actual graphics code is all done in C. There are no popular C++ graphics libraries. Sorry. Its not possible, graphics libraries require hardware acceleartion. Sure there are C++ wrappers around the C libraries that do the acceleration, so you are loosly correct. But the actual graphics code is all done in C.
the (realtime) graphics/gaming industry is notorious for being among the latest adopters when it comes to platform/toolchain. some of this is well-founded because of special requirements like compile-time and efficient debug-builds, but a lot of it is also for reasons I can only speculate resemble the opinion you expressed above. if you want to help boost to better meet the requirements of that industry I'm sure you're welcome to do so. a good starting point would be to read this document by your colleagues at EA about their implementation of STL, intrusive containers and more, specifically tuned towards gaming/realtime graphics: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html it's from 2007, so it can only be another decade until your industry switches to Windows...I mean, switches to C++.
Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. [cut] There are no popular C++ graphics libraries. [cut]
Gamebryo. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++ *and* boost.
Not true. [cut] There are no popular C++ graphics libraries. [cut]
Gamebryo.
OGRE, Irlicht3D, Infernal. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Wed, Mar 24, 2010 at 2:05 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
Rene Rivera wrote:
Tom Brinkman wrote:
To you. There are many graphics shops that make extensive use of c++
*and* boost.
Not true. [cut] There are no popular C++ graphics libraries. [cut]
Gamebryo.
OGRE, Irlicht3D, Infernal.
Crystal Space 3d, Direct 3d
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ________________ ::matus_chochlik
On Mar 23, 2010, at 7:21 PM, Tom Brinkman wrote:
Those of us that started out learning C++ before ever learning C, have had to do lots of backfilling.
I assume too much from my own experience, as do you. The truth is probably found in between. I *think* it is safe to say that most (self-proclaimed is sufficient for now...) masters of C++ used to be a "typical C developer" a decade or two ago, no?
By learning C, what I mean is getting really good at pointer manipulations and managing memory yourself.
I assumed most intermediate C++ developers (and above) were very familiar with stacks (and stack frames) and (most common implementations of) heaps. You do not think they are? I am not talking but people who have developed in VB for over six years and then suddenly, after having used VB.NET for almost two years, get dragged into an MFC project, since they "know GUI programming" :-)
C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer.
Repeating the request of many others: can you provide an example?
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
Ah, I had no idea that it had become that bad. I used to be a graphics programmer (you know, building my own 3D and physics engines, using lots of other game and 3D engines) in the good old days, when men had hair on their knuckles, and it was actually quite a lot of C++. What kind of graphics programming do you do, if I may ask?
However, I'm originally a C++ developer, and i'm still a boost/C++ supporter.
Yes, you are. What strikes me as confusing is that you use MPL regularly yet get a bit frustrated over too many (and probably too deep...) templates. A person who uses MPL regularly surely must appreciate the beauty of Boost (and of C++) relative the most common C libraries? APR, NSPR, all those parameters and "foo_t *another_struct" everywhere...
For Boost to remain relevent, it needs to reflect the reality of modern development. That is most projects are mixed C/C++ projects. The needs of both communities need to be met.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
Boost is a C++ library framework. That is true. It has already lost its relevance among Rubyists. Yes, I know that "C" has a special status among "native developers." Of course. It is the lingua franca for what I previously called 'glue' between components. The mere fact that C++ has its roots in C should not make it less of a distinct and autonomous language than, say, D, which also makes use of a lot of C libraries. Would you argue the same points for a D-specific library?
I'm just saying what people are thinking.
I believe you, with the tacit assumption that you mean "you" by your use of "people." /David
On Tue, Mar 23, 2010 at 4:03 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
Sometimes it feels like Linus has a lot of aliases on these lists ;-)
I especially liked the - partly retracted, admittedly - statement that C++ developers have a lot to learn from the typical C developer, but probably not the other way around. Especially in the light of the typical C++ developer often having been a typical C developer 7 years earlier. And most master C++ developers having been typical C developers 14-22 years ago.
The only point with which I agree is those ugly macros. Yes, I know why we need them, but they are still ugly. BUT, PP is a splendid engineering effort (in retrofitting the C++ preprocessor for tasks it was not meant to handle.)
Boost is the only set of libraries in a "conventional" language that do as I think, which is why it is good :-)
/David
On Mar 23, 2010, at 6:48 PM, Emil Dotchevski wrote:
In any event, my point is that c++ exception handeling should be
On Tue, Mar 23, 2010 at 2:43 PM, Tom Brinkman <reportbase2007@gmail.com> wrote: optional.
Boost libraries need to be updated to reflect this.
Look at the design of C++ constructors: the postcondition of a constructor is that the object instance is initialized successfully. Had Stroustrup listened to people arguing about "optional" exception handling, the C++ constructors would have been useless because they wouldn't have that postcondition.
It is the same with any other use of exceptions. Make them optional, and you throw away the *only* reason to use them in the first place: to enforce postconditions.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
masters of C++ used to be a "typical C developer" a decade or two ago, no?
Fair statement. Agreed.
You do not think they are?
In my experience, developers like your self, who started in C, are much better developers, than those of us that that started in C++. You have much better perspectives and a more balanced approch to interface design. So yes, I agree with your larger point.
Repeating the request of many others: can you provide an example?
I'll try later.
What kind of graphics programming do you do, if I may ask?
Movies. Also wrote a popular charting library.
Would you argue the same points for a D-specific library?
I see your point.
I believe you, with the tacit assumption that you mean "you" by your use of "people."
Sorry, yes, thats what I meant. On Tue, Mar 23, 2010 at 4:39 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
On Mar 23, 2010, at 7:21 PM, Tom Brinkman wrote:
Those of us that started out learning C++ before ever learning C, have had to do lots of backfilling.
I assume too much from my own experience, as do you. The truth is probably found in between. I *think* it is safe to say that most (self-proclaimed is sufficient for now...) masters of C++ used to be a "typical C developer" a decade or two ago, no?
By learning C, what I mean is getting really good at pointer manipulations and managing memory yourself.
I assumed most intermediate C++ developers (and above) were very familiar with stacks (and stack frames) and (most common implementations of) heaps. You do not think they are? I am not talking but people who have developed in VB for over six years and then suddenly, after having used VB.NET for almost two years, get dragged into an MFC project, since they "know GUI programming" :-)
C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer.
Repeating the request of many others: can you provide an example?
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
Ah, I had no idea that it had become that bad. I used to be a graphics programmer (you know, building my own 3D and physics engines, using lots of other game and 3D engines) in the good old days, when men had hair on their knuckles, and it was actually quite a lot of C++. What kind of graphics programming do you do, if I may ask?
However, I'm originally a C++ developer, and i'm still a boost/C++ supporter.
Yes, you are. What strikes me as confusing is that you use MPL regularly yet get a bit frustrated over too many (and probably too deep...) templates. A person who uses MPL regularly surely must appreciate the beauty of Boost (and of C++) relative the most common C libraries? APR, NSPR, all those parameters and "foo_t *another_struct" everywhere...
For Boost to remain relevent, it needs to reflect the reality of modern development. That is most projects are mixed C/C++ projects. The needs of both communities need to be met.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
Boost is a C++ library framework. That is true. It has already lost its relevance among Rubyists. Yes, I know that "C" has a special status among "native developers." Of course. It is the lingua franca for what I previously called 'glue' between components. The mere fact that C++ has its roots in C should not make it less of a distinct and autonomous language than, say, D, which also makes use of a lot of C libraries. Would you argue the same points for a D-specific library?
I'm just saying what people are thinking.
I believe you, with the tacit assumption that you mean "you" by your use of "people."
/David
On Tue, Mar 23, 2010 at 4:03 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
Sometimes it feels like Linus has a lot of aliases on these lists ;-)
I especially liked the - partly retracted, admittedly - statement that
developers have a lot to learn from the typical C developer, but
C++ probably
not the other way around. Especially in the light of the typical C++ developer often having been a typical C developer 7 years earlier. And most master C++ developers having been typical C developers 14-22 years ago.
The only point with which I agree is those ugly macros. Yes, I know why we need them, but they are still ugly. BUT, PP is a splendid engineering effort (in retrofitting the C++ preprocessor for tasks it was not meant to handle.)
Boost is the only set of libraries in a "conventional" language that do as I think, which is why it is good :-)
/David
On Mar 23, 2010, at 6:48 PM, Emil Dotchevski wrote:
In any event, my point is that c++ exception handeling should be
On Tue, Mar 23, 2010 at 2:43 PM, Tom Brinkman < reportbase2007@gmail.com> wrote: optional.
Boost libraries need to be updated to reflect this.
Look at the design of C++ constructors: the postcondition of a constructor is that the object instance is initialized successfully. Had Stroustrup listened to people arguing about "optional" exception handling, the C++ constructors would have been useless because they wouldn't have that postcondition.
It is the same with any other use of exceptions. Make them optional, and you throw away the *only* reason to use them in the first place: to enforce postconditions.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 23, 2010 at 6:07 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
In my experience, developers like your self, who started in C, are much better developers, than those of us that that started in C++. You have much better perspectives and a more balanced approch to interface design. So yes, I agree with your larger point.
IME, there is no evidince to support this assertion, or the contrary. However, this is *way* off topic. If you would like to argue the merits of C over C++, what you *can't* do with C++, whether C++ is relevant as a language, or <insert your OFF-topic here>, then please take it on over to comp.lang.c++. Thanks, Jon
On Tue, Mar 23, 2010 at 5:12 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 6:07 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
In my experience, developers like your self, who started in C, are much better developers, than those of us that that started in C++. You have much better perspectives and a more balanced approch to interface design. So yes, I agree with your larger point.
However, this is *way* off topic. If you would like to argue the merits of C over C++, what you *can't* do with C++, whether C++ is relevant as a language, or <insert your OFF-topic here>, then please take it on over to comp.lang.c++.
In my mind, a discussion about whether or not C-style interfaces are better fit for expressing certain designs is entirely on topic. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Mar 23, 2010 at 6:21 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
In my mind, a discussion about whether or not C-style interfaces are better fit for expressing certain designs is entirely on topic.
Let's stick to the specific current and proposed boost interfaces then, and how they would benefit from a C- vs. C++-style interface. Jon
Tom Brinkman wrote:
Those of us that started out learning C++ before ever learning C, have had to do lots of backfilling.
By learning C, what I mean is getting really good at pointer manipulations and managing memory yourself.
I started with a couple of years of C programming (following BASIC, FORTRAN, etc.), moved on to C++ in 1987, IIRC, and never looked back. Even so, I once did all the code I could using pointers and pointer arithmetic, just to cement those concepts in my mind. Others, of course, spent more time with C before moving to C++. The point is that many hard core C++ programmers actually know something about C, too.
C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer.
What are those? I can't say I know of anything that fits that description. If you can give concrete examples, we could make them Boost guidelines.
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
Ah, now we come to the crux of the matter. In your world, "C++ is practically useless," so that generalizes to the rest of the programming world and means Boost isn't relevant to today's programmers.
For Boost to remain relevent, it needs to reflect the reality of modern development. That is most projects are mixed C/C++ projects. The needs of both communities need to be met.
I reject your statement out of hand. Most projects are not mixed C and C++. Some are, some aren't. We don't do *any* C here, for example.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
I'm just saying what people are thinking.
You're just saying what *some* people are saying. The question is whether there are things Boost can do better that would be of use to all, not just to C programmers. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer.
What are those? I can't say I know of anything that fits that description. If you can give concrete examples, we could make them Boost guidelines.
Easy, object orientated developement. I am a functional style programmer, as are most boost developers. Thats why I follow boost. I hate OO style code. I regularly show my collegues cool functional programming techniques that I learned here on boost. You would be surprised how "C" orientated programmers can quickly be converted to functional programming if you just show them small simple examples of what its all about. This is where boost has not met its potential. Education. So much more could be done to educate the masses about the wonders of functional programming.
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
Ah, now we come to the crux of the matter. In your world, "C++ is practically useless," so that generalizes to the rest of the programming world and means Boost isn't relevant to today's programmers.
For Boost to remain relevent, it needs to reflect the reality of modern development. That is most projects are mixed C/C++ projects. The needs of both communities need to be met.
I reject your statement out of hand. Most projects are not mixed C and C++. Some are, some aren't. We don't do *any* C here, for example.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
I'm just saying what people are thinking.
You're just saying what *some* people are saying. The question is whether there are things Boost can do better that would be of use to all, not just to C programmers.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman wrote:
C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer.
What are those? I can't say I know of anything that fits that description. If you can give concrete examples, we could make them Boost guidelines.
Easy, object orientated developement.
Object oriented development is just one of several paradigms supported by C++. The language hardly encourages it over the others, regardless of its popularity with any given group of C++ developers. I happen to write a good deal of OO code and it works very well for me and those using my code. I also write functional code, depending on the need.
I am a functional style programmer, as are most boost developers. Thats why I follow boost. I hate OO style code.
There sure are an awful lot of classes in Boost for such a functional-style focus as you describe.
I regularly show my collegues cool functional programming techniques that I learned here on boost.
You would be surprised how "C" orientated programmers can quickly be converted to functional programming if you just show them small simple examples of what its all about.
C programmers write a good deal of object oriented code. Just look at all of the opaque handles they create with associated functions to manipulate a data structure. That has been the basis for a great deal of C code over the years and it hasn't been a bad thing. Functional programming is not a panacea. It is another tool in the box. It should be used more than it is, but it doesn't replace other approaches generally.
This is where boost has not met its potential. Education. So much more could be done to educate the masses about the wonders of functional programming.
By virtue of template metaprogramming, there is a good deal of functional programming in Boost. However, we've already observed problems with that programming style in this thread. Languages like Haskell make functional programming first class and should probably be preferred when doing only functional programming. That leaves me to wonder how much Boost can or should do "to educate the masses about the wonders of functional programming." _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Tom Brinkman wrote:
I am a functional style programmer, as are most boost developers. Thats why I follow boost. I hate OO style code.
And I guess that's why at least some of us who consider ourselves to be 'programmers who use C++' are sometimes rather concerned with the direction things seem to go in sometimes. Did I imagine finding inheritance and vtables useful?
This is where boost has not met its potential. Education. So much more could be done to educate the masses about the wonders of functional programming.
Yeah, some of us don't entirely like functional programming so clearly we need to be 'educated'. Thanks. :-(
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
Ah, now we come to the crux of the matter. In your world, "C++ is practically useless," >>> so that generalizes to the rest of the programming world and means Boost isn't relevant >>> to today's programmers.
I should restate my point here. In hard-core graphics programming, its all just about manipulating memory buffers. Which, for the most part, is just straight "C", or for many just assembly language. Yes, lots of assembly language is still done in graphics programming. I in now way tried to generalize that boost isn't relevent to todays programmers. Quite the contrary -- boost is my favorite place to see what the "experts" are up to in the "functional" space. In my view, boost developers are the best of the best. I really believe that.
Tom Brinkman wrote:
Those of us that started out learning C++ before ever learning C, have had to do lots of backfilling.
By learning C, what I mean is getting really good at pointer manipulations and managing memory yourself.
C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer.
Such as?
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
Oh, cool so I am paid to do a lot of useless work. Nice. I do a lot of graphics programming (medical imaging), and have never encountered any C here (and most libs in the field are written in pure and reasonably modern c++), unless you count interfacing with OpenGL, which in my experience is also greatly helped by using C++ techniques like using RAII wrappers. From my perspective I never see mixed C/C++ projects, rather C++ and Lua or Python.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
I'm just saying what people are thinking.
... in your particular environment. Regards Fabio
If you read the whole thread, which I dont suggest, I clarified my comments. I said hardware accelerated graphics coding is done in assembly and some C. Of course, you can do graphics programming in any language including Lua. Wrappers have been created over the years for every higher level graphics language. On Wed, Mar 24, 2010 at 1:24 PM, Fabio Fracassi <f.fracassi@gmx.net> wrote:
Tom Brinkman wrote:
Those of us that started out learning C++ before ever learning C, have had to do lots of backfilling.
By learning C, what I mean is getting really good at pointer manipulations and managing memory yourself.
C++ encourages all sorts of programming practices that I wish I never learned and have never been very useful to me as a programmer.
Such as?
Sorry to say, but as a graphics programer, C++ is practically useless. Its all C.
Oh, cool so I am paid to do a lot of useless work. Nice. I do a lot of graphics programming (medical imaging), and have never encountered any C here (and most libs in the field are written in pure and reasonably modern c++), unless you count interfacing with OpenGL, which in my experience is also greatly helped by using C++ techniques like using RAII wrappers.
From my perspective I never see mixed C/C++ projects, rather C++ and Lua or Python.
Because boost only meets the needs of C++ developers, it will continue to loose relevance.
I'm just saying what people are thinking.
... in your particular environment.
Regards
Fabio
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman wrote:
If you read the whole thread, I have, ...
which I dont suggest, ... why not, I quite enjoyed it. (I have some strange taste sometimes :) )
I clarified my comments. I said hardware accelerated graphics coding is done in assembly and some C.
Which is where I don't quite agree. A former coworker of mine wrote a (academically oriented) lib which loaded of the work to either gpu or cpu (compile time choice) with the same code (which looked simmilar to boost.ublas). The performance was au-par with cuda or handwritten shader code, and that without using any too sophisticated optimisations. Of course there was some assembly and some c code (OpenGL calls) in the back end. I think in mid term libs like that will aleviate the need to stoop to the lower hells (just kidding) of c code.
Of course, you can do graphics programming in any language including Lua. Wrappers have been created over the years for every higher level graphics language.
Thats not what I meant. Regards Fabio
All valid points of view. You should create a top level thread if you want carry this discussion forward. I'll see you there. On Wed, Mar 24, 2010 at 3:59 PM, Fabio Fracassi <f.fracassi@gmx.net> wrote:
Tom Brinkman wrote:
If you read the whole thread,
I have, ...
which I dont suggest,
... why not, I quite enjoyed it. (I have some strange taste sometimes :) )
I clarified my comments. I said hardware accelerated graphics coding is done in assembly and some C.
Which is where I don't quite agree. A former coworker of mine wrote a (academically oriented) lib which loaded of the work to either gpu or cpu (compile time choice) with the same code (which looked simmilar to boost.ublas). The performance was au-par with cuda or handwritten shader code, and that without using any too sophisticated optimisations.
Of course there was some assembly and some c code (OpenGL calls) in the back end.
I think in mid term libs like that will aleviate the need to stoop to the lower hells (just kidding) of c code.
Of course, you can do graphics programming in any language including Lua. Wrappers have been created over the years for every higher level graphics language.
Thats not what I meant.
Regards
Fabio
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 23 March 2010 17:43, Tom Brinkman <reportbase2007@gmail.com> wrote:
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
One of the first thing that comes up when a mixed language C/C++ project uses a C++ library is: Does this library throw exceptions?
Generally and unfortunately, if the answer is yes, that library will be ignored out of hand.
At which point they'll go find some C library and proceed to ignore most of the return codes and errno changes.
Tom Brinkman wrote:
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new.
My point was that it is very hard to avoid exceptions in C++. Two-phase construction is untenable for the same reasons that C APIs are a pain to use: you have to remember to check the error state(s). Without two-phase construction, you have to decrease performance by checking object validity in every member function or else throw an exception to indicate improper construction. Exceptions look pretty good in that light.
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
I already agreed that more could be done in that direction and suggested that you should try to push those ideas into the existing and future libraries.
One of the first thing that comes up when a mixed language C/C++ project uses a C++ library is: Does this library throw exceptions?
Generally and unfortunately, if the answer is yes, that library will be ignored out of hand.
Is it a big deal that "hard core" C++ libraries aren't acceptable to C programmers?
2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style.
Boost.Format provides what you want. There's relatively little output from the various libraries, so I don't see where this issue arises in real use cases.
This is a real issue.
Which Boost library produces output using IOStreams that is causing the problem?
Boost.format is not a replacement for Printf -- they have different syntaxes.
The syntax is quite similar. My goodness, cannot C programmers acknowledge the benefits of type safety and extensibility to learn a slightly different syntax?
Printf style arguments are the prevailing api style. No one is asking for printf style arguments to be replaced.
Untrue. Many dislike printf()-style I/O because of the lack of safety and extensibility.
Why replace something that is the standard and works just fine.
It doesn't work "just fine." There are many problems with printf(). Here's a question: how much of that wonderful code that uses printf() actually checks the return code and handles the errors reported by printf()?
This is just symptomatic of my larger point that boost is a research project and not relevent to day to day C/C++ programmers.
This is just flat wrong. Boost is relevant to a very large number of "day to day" C++ programmers. I really don't care much about C programmers and I don't think Boost should either. I don't mean to suggest that we should be antagonistic towards their needs. After all, making a C programmer happy, without making a C++ programmer unhappy, implies a straightforward, simplistic API. Those are easy to understand. However, when doing so is unduly inefficient or unsafe, then the C++ programmer wants more and the C programmer will probably be unhappy.
If boost developers want to create an alternative to printf, that is fine. However, it should be just that, an alternative, not a replacement.
Boost has alternatives that satisfy -- to some degree, anyway -- the concerns of C++ programmers. Since printf() is not "just fine," this is a good thing. Since printf() has problems, why should Boost, a group that seeks to advance C++ -- not C -- persist in using an I/O mechanism that has problems? The alternatives may not be perfect, but they are attempts to correct the problems of printf().
Printf style api's are easy to implement. There are reasons not to do them.
I'm glad you recognize that there are reasons to avoid them. (You probably meant to write "there are no reasons not to do them," but I couldn't help myself.) Clearly we have a problem. You haven't identified any concrete examples where a printf()-style interface is lacking and I don't accept your generalization that printf() is clearly superior to the C++ alternatives.
3) Dependencies.
Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't.
The dependencies aren't confusing so much as complex. Would you have each library in Boost reinvent rather than reuse other Boost functionality? Isn't that the point of Boost libraries: reuse functionality written by others?
It can absolutely be an issue if one of the dependent libraries throws exceptions for example. Because boost does not have clearly stated policy about exceptions, who knows what changes occured between versions.
Boost doesn't have a clearly stated policy about exceptions which means, given that they are C++ libraries, exceptions are allowed at the library author's discretion. There are many satisfied with exceptions in C++ libraries. Obviously, you and those around you aren't. That hardly generalizes to the majority.
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
I don't see why dependencies among Boost libraries would lead to picking and choosing which are approved.
This is a key issue. Because boost does not allow you to choose only select libraries, you must use all of boost.
You haven't addressed my earlier question: why shouldn't Boost libraries reuse others? If those dependencies aren't managed as nicely as they otherwise could be, make concrete suggestions. However, asking Boost libraries to be independent of all the rest is a ridiculous imposition.
Project prefer safety to features. If the risks of using boost are unclear without is clear policies about exceptions and depencies, its easier to not use boost at all so its abandoned in its entirety, no matter how much you want to use a specific library.
Projects have different needs. Many projects expect and program for exceptions. Such projects will have no problem with this "scary" and "unspecified" aspect of Boost. Even combined C/C++ projects can wrap useful Boost functionality into a C API or use Boost in the C++ layers, catch and translate all exceptions into error codes, and provide something useful for the C programmers. This is hardly news to most working with both languages. It seems that you want Boost to cater to C programmers' needs, which is antithetical to Boost's purpose. It is reasonable to ask for specific changes to make throwing exceptions optional, but I don't find anything else concrete in what you're complaining about. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 03/24/2010 08:25 AM, Stewart, Robert wrote:
Tom Brinkman wrote:
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new.
My point was that it is very hard to avoid exceptions in C++. Two-phase construction is untenable for the same reasons that C APIs are a pain to use: you have to remember to check the error state(s). Without two-phase construction, you have to decrease performance by checking object validity in every member function or else throw an exception to indicate improper construction. Exceptions look pretty good in that light.
Very true.
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
I already agreed that more could be done in that direction and suggested that you should try to push those ideas into the existing and future libraries.
I strongly disagree on this. Wasn't one perceived drawback of Boost its use of macros ? The main reason for the use of macros seems to me to be to work around deficient compilers, i.e. portability. If you really want to promote the idea of making standard C++ features optional, you are getting even more macros and convoluted logic to satisfy all those different needs. I don't think Boost needs more variability and flexibility. I'd actually favor cleaning it up by removing support for obsolete platforms and tools. Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
On 03/24/2010 08:25 AM, Stewart, Robert wrote:
Tom Brinkman wrote:
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
I already agreed that more could be done in that direction and suggested that you should try to push those ideas into the existing and future libraries.
I strongly disagree on this. Wasn't one perceived drawback of Boost its use of macros ? The main reason for the use of macros seems to me to be to work around deficient compilers, i.e. portability. If you really want to promote the idea of making standard C++ features optional, you are getting even more macros and convoluted logic to satisfy all those different needs.
I was referring to the approach espoused by Boost.System.
I don't think Boost needs more variability and flexibility. I'd actually favor cleaning it up by removing support for obsolete platforms and tools.
I can't argue with that, in general. When support is dropped for the platforms I need, I'll have a different opinion, of course. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stefan Seefeld wrote:
I strongly disagree on this. Wasn't one perceived drawback of Boost its use of macros ? The main reason for the use of macros seems to me to be to work around deficient compilers, i.e. portability.
Probably not the best place in this long thread to say this, but I don't see what's wrong with macros. They're a great way to generate code in ways that are impossible with templates (and are sometimes faster as well) and can really help in reducing code duplication. Granted, they're a bit hard to use, but sometimes they're worth it. The fact most programmers don't know the preprocessor is not a good reason to ban its usage.
Regarding Exception Handeling. . Is it a big deal that "hard core" C++ libraries aren't acceptable to C programmers?
Its a pretty big deal to some developers. To some, its the first thing the look for when they consider a C++ library. In my view, its not that big of a deal. Just wrap the damn call into a try-catch block, be done with it. The issue has more to do with considering the needs of preferences of the prevailing style of development of those developers that are more "C" orientated. Of course, Boost is a C++ library, and boost developers should consider the needs of C++ developers first when they develop their api's. Of course, I'm not suggesting boost converts to be a "C" library. But what I am trying to say, albeit not very well, is that boost and C++ in general should try be a little more "C" friendly. (When I say boost, what I really mean is boost/C++). In my view, for the most part, its rather simple to make C++ code, "somewhat" C friendly. (I'll try to detail some ways that C++ developers can do this in a latter post). The easy one is "printf", which we endlessly discussed. Yes, printf style API's have issues, although GCC and ICC, have practically eliminated most of the worst of them. Not sure about other compilers. Sure printf has warts, however, for the most they are considered to be good enough. Iostream also warts, but for the most part it is good enough. Thats not really my point. Its more that it would go along way towards lessening the animosity that "C" developers have towards "C++" if at least some small effort was made. Supporting at least of some of the eaiser to implement "C" friendly style API's, such as printf, would make it seem like at least your trying and then maybe, just maybe, I could generate some support on my teams for using those boost C++ libraries again. A small effort would go along way. On Wed, Mar 24, 2010 at 5:25 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Tom Brinkman wrote:
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new.
My point was that it is very hard to avoid exceptions in C++. Two-phase construction is untenable for the same reasons that C APIs are a pain to use: you have to remember to check the error state(s). Without two-phase construction, you have to decrease performance by checking object validity in every member function or else throw an exception to indicate improper construction. Exceptions look pretty good in that light.
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
I already agreed that more could be done in that direction and suggested that you should try to push those ideas into the existing and future libraries.
One of the first thing that comes up when a mixed language C/C++ project uses a C++ library is: Does this library throw exceptions?
Generally and unfortunately, if the answer is yes, that library will be ignored out of hand.
Is it a big deal that "hard core" C++ libraries aren't acceptable to C programmers?
2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style.
Boost.Format provides what you want. There's relatively little output from the various libraries, so I don't see where this issue arises in real use cases.
This is a real issue.
Which Boost library produces output using IOStreams that is causing the problem?
Boost.format is not a replacement for Printf -- they have different syntaxes.
The syntax is quite similar. My goodness, cannot C programmers acknowledge the benefits of type safety and extensibility to learn a slightly different syntax?
Printf style arguments are the prevailing api style. No one is asking for printf style arguments to be replaced.
Untrue. Many dislike printf()-style I/O because of the lack of safety and extensibility.
Why replace something that is the standard and works just fine.
It doesn't work "just fine." There are many problems with printf(). Here's a question: how much of that wonderful code that uses printf() actually checks the return code and handles the errors reported by printf()?
This is just symptomatic of my larger point that boost is a research project and not relevent to day to day C/C++ programmers.
This is just flat wrong. Boost is relevant to a very large number of "day to day" C++ programmers. I really don't care much about C programmers and I don't think Boost should either. I don't mean to suggest that we should be antagonistic towards their needs. After all, making a C programmer happy, without making a C++ programmer unhappy, implies a straightforward, simplistic API. Those are easy to understand. However, when doing so is unduly inefficient or unsafe, then the C++ programmer wants more and the C programmer will probably be unhappy.
If boost developers want to create an alternative to printf, that is fine. However, it should be just that, an alternative, not a replacement.
Boost has alternatives that satisfy -- to some degree, anyway -- the concerns of C++ programmers. Since printf() is not "just fine," this is a good thing. Since printf() has problems, why should Boost, a group that seeks to advance C++ -- not C -- persist in using an I/O mechanism that has problems? The alternatives may not be perfect, but they are attempts to correct the problems of printf().
Printf style api's are easy to implement. There are reasons not to do them.
I'm glad you recognize that there are reasons to avoid them. (You probably meant to write "there are no reasons not to do them," but I couldn't help myself.) Clearly we have a problem. You haven't identified any concrete examples where a printf()-style interface is lacking and I don't accept your generalization that printf() is clearly superior to the C++ alternatives.
3) Dependencies.
Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't.
The dependencies aren't confusing so much as complex. Would you have each library in Boost reinvent rather than reuse other Boost functionality? Isn't that the point of Boost libraries: reuse functionality written by others?
It can absolutely be an issue if one of the dependent libraries throws exceptions for example. Because boost does not have clearly stated policy about exceptions, who knows what changes occured between versions.
Boost doesn't have a clearly stated policy about exceptions which means, given that they are C++ libraries, exceptions are allowed at the library author's discretion. There are many satisfied with exceptions in C++ libraries. Obviously, you and those around you aren't. That hardly generalizes to the majority.
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
I don't see why dependencies among Boost libraries would lead to picking and choosing which are approved.
This is a key issue. Because boost does not allow you to choose only select libraries, you must use all of boost.
You haven't addressed my earlier question: why shouldn't Boost libraries reuse others? If those dependencies aren't managed as nicely as they otherwise could be, make concrete suggestions. However, asking Boost libraries to be independent of all the rest is a ridiculous imposition.
Project prefer safety to features. If the risks of using boost are unclear without is clear policies about exceptions and depencies, its easier to not use boost at all so its abandoned in its entirety, no matter how much you want to use a specific library.
Projects have different needs. Many projects expect and program for exceptions. Such projects will have no problem with this "scary" and "unspecified" aspect of Boost.
Even combined C/C++ projects can wrap useful Boost functionality into a C API or use Boost in the C++ layers, catch and translate all exceptions into error codes, and provide something useful for the C programmers. This is hardly news to most working with both languages.
It seems that you want Boost to cater to C programmers' needs, which is antithetical to Boost's purpose. It is reasonable to ask for specific changes to make throwing exceptions optional, but I don't find anything else concrete in what you're complaining about.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman a écrit :
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new.
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
The C++ standard library throws exceptions. You probably use it, as a lot of other C++ developers do, while claiming things like containers of types that don't throw exceptions don't throw exceptions, but yes, they do (since they call operator new, which throws, and have no other way of reporting errors anyway). How can you expect Boost to be any different than the standard library? Even Qt recently left no-exception-make-believe-land when they realized it hurt them more than they anticipated, and now they have to reaudit everything to ensure exception-safety, because the code was never written with that in mind... Exceptions are an all or nothing thing. You can't just make them optional or be exception-agnostic. In all cases, all C++ code should be exception safe, unless you choose to restrict yourself to a dialect of C++ where exceptions do not exist, that is say C.
Exceptions are an all or nothing thing.
Yeah, maybe true. Sad, because, that's one of the most cited reason for "C" inclined developers to dismiss "C++" libraries. When you work with mixed teams of C/C++ guys, they argue about this all the time. I'm not sure there is an elegant solution to this dilemma either. On Sun, Mar 28, 2010 at 5:08 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Tom Brinkman a écrit :
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Exceptions are a fact of C++ life. You can't avoid them if for no other
reason than std::bad_alloc, unless you don't allocate from the free store.
Not true, there are no-throw versions of std::new.
In any event, my point is that c++ exception handeling should be optional. Boost libraries need to be updated to reflect this.
The C++ standard library throws exceptions. You probably use it, as a lot of other C++ developers do, while claiming things like containers of types that don't throw exceptions don't throw exceptions, but yes, they do (since they call operator new, which throws, and have no other way of reporting errors anyway).
How can you expect Boost to be any different than the standard library? Even Qt recently left no-exception-make-believe-land when they realized it hurt them more than they anticipated, and now they have to reaudit everything to ensure exception-safety, because the code was never written with that in mind...
Exceptions are an all or nothing thing. You can't just make them optional or be exception-agnostic. In all cases, all C++ code should be exception safe, unless you choose to restrict yourself to a dialect of C++ where exceptions do not exist, that is say C.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mar 28, 2010, at 9:58 PM, Tom Brinkman wrote:
Exceptions are an all or nothing thing.
Yeah, maybe true. Sad, because, that's one of the most cited reason for "C" inclined developers to dismiss "C++" libraries. When you work with mixed teams of C/C++ guys, they argue about this all the time.
I'm not sure there is an elegant solution to this dilemma either.
Yes, there is. Use C. /David
Sadly, that's what they do, or if not, they just ignore this issue and pretend it will just go away. As most of my recent projects have been mixed C/C++, I get to use boost less and less, or at all now. On Sun, Mar 28, 2010 at 7:10 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Mar 28, 2010, at 9:58 PM, Tom Brinkman wrote:
Exceptions are an all or nothing thing.
Yeah, maybe true. Sad, because, that's one of the most cited reason for "C" inclined developers to dismiss "C++" libraries. When you work with mixed teams of C/C++ guys, they argue about this all the time.
I'm not sure there is an elegant solution to this dilemma either.
Yes, there is. Use C.
/David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman wrote:
Sadly, that's what they do,
or if not,
they just ignore this issue and pretend it will just go away.
As most of my recent projects have been mixed C/C++, I get to use boost less and less, or at all now.
Are the guys making C the guy that pay you ? I was naively thinking that in those case, there can be like - a discussion - about such issues ... What super powers does the C guy has so THEIR decision has more weight than the C++ guys one ? "you know I don't like how C is uglyly allocating memory, so *I* will force you to use C++" Using fallacies and FUD works both way :o
On 28 March 2010 21:20, Tom Brinkman <reportbase2007@gmail.com> wrote:
Sadly, that's what they do,
or if not,
they just ignore this issue and pretend it will just go away.
As most of my recent projects have been mixed C/C++, I get to use boost less and less, or at all now.
While we can feel your pain, we cannot solve political issues inside your company. No exceptions means no STL, two phase construction for everything, etc. If I had to go back to writing code like that, I wouldn't much like C++ either. Even if we magically changed all of Boost, would these guys commit to using it? I suspect exceptions are but one in a whole litany of emotional, not technical arguments. Regards, -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Stewart, Robert wrote:
Tom Brinkman wrote:
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Write once code is easy to create, of course, but if you can't grok what's in a Boost library, then don't bother. Treat it like a black box.
Ah, the famous black box. I only wish the compiler would also understand that he has to treat the Boost library like a black box when emitting warnings and error messages. For the debugger, I even wish it could understand the semantics of the stored data, so that it could show me the data in a usable and easily readable format.
What is the practical value of a library that can only be maintained by the original developer(s)?
You write to the interface and if the library provides useful functionality, you're golden!
Even so I doubt very much that Boost libraries fall into the category of code that can only be maintained by original developer(s), your answer shocks me. In my experience, a developer that is not able to write code that can be understood and maintained by other developers sooner or later gets overwhelmed by the task to maintain his own unmaintainable code.
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
I don't understand why a library is "very dangerous to use" if you can't understand its implementation. That just suggests that you want Boost to be dumbed down for some arbitrarily low experience level.
Tom wasn't talking about completely understanding the code. He just said "some idea what it's doing". And he hasn't suggested to assume some "arbitrarily low experience level". But I have to admit that it took me significantly longer "than a day" to have "some idea" of how "qt" is working. I definitely agree that it is dangerous to use a library without having "some idea what it's doing". The question whether "qt" is dangerous or not is more complicated. Now "qt" is indeed a bit dangerous, but so is any other reasonable GUI toolkit. But if the choice would be use "qt" or have "no GUI at all", taking the "no GUI at all" option might indeed be significantly less dangerous. OK, now I drifted off a bit. My point is that I really have to disagree with your statement "I don't understand why a library is "very dangerous to use" if you can't understand its implementation." Denying the need for quality is not a good response if somebody suggests you might have quality problems. Regards, Thomas
AMDG Thomas Klimpel wrote:
Stewart, Robert wrote:
Tom Brinkman wrote:
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Write once code is easy to create, of course, but if you can't grok what's in a Boost library, then don't bother. Treat it like a black box.
Ah, the famous black box. I only wish the compiler would also understand that he has to treat the Boost library like a black box when emitting warnings and error messages. For the debugger, I even wish it could understand the semantics of the stored data, so that it could show me the data in a usable and easily readable format.
Perhaps you would find this useful: https://svn.boost.org/trac/boost/wiki/DebuggerVisualizers In Christ, Steven Watanabe
Steven Watanabe wrote:
Perhaps you would find this useful: https://svn.boost.org/trac/boost/wiki/DebuggerVisualizers
I will definitively try this out tomorrow, and tell you how it works for me. Regards, Thomas
Thomas Klimpel wrote:
Steven Watanabe wrote:
Perhaps you would find this useful: https://svn.boost.org/trac/boost/wiki/DebuggerVisualizers
I will definitively try this out tomorrow, and tell you how it works for me.
I tried it out now. I really find this useful. Thank you very much. I just finished writing similar debug visualizers for 8 of our internally used data structures. And now I will have to tell everybody... Regards, Thomas
Thomas Klimpel wrote:
Stewart, Robert wrote:
Tom Brinkman wrote:
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Write once code is easy to create, of course, but if you can't grok what's in a Boost library, then don't bother. Treat it like a black box.
Ah, the famous black box. I only wish the compiler would also understand that he has to treat the Boost library like a black box when emitting warnings and error messages. For the debugger, I even wish it could understand the semantics of the stored data, so that it could show me the data in a usable and easily readable format.
Diagnostics from templated code is a problem. Better use of Boost.Concept Checking would help. Concepts in C++ were to have addressed this much more completely, but had to be deferred. Boost is not alone in regard to debugging issues. Templates can make type names longer and more confusing, but it doesn't change the underlying issue: C++ type composition can be complex. That arises from the ability of the language to better abstract complicated type relationships.
What is the practical value of a library that can only be maintained by the original developer(s)?
You write to the interface and if the library provides useful functionality, you're golden!
Even so I doubt very much that Boost libraries fall into the category of code that can only be maintained by original developer(s), your answer shocks me. In my experience, a developer that is not able to write code that can be understood and maintained by other developers sooner or later gets overwhelmed by the task to maintain his own unmaintainable code.
If a library can only be maintained by one or two people in the world, this would be a problem. However, I took Tom's question as hyperbole. There are many developers on this list who could maintain any Boost library. There might be some need for education to gain specialized domain knowledge in some cases, but the techniques are not beyond a good number of developers on this list. I take Tom's question as, if the everyday C/C++ programmer can't understand the library, it's no good to those programmers. That's ridiculous. Those same programmers probably would struggle to understand printf()'s or pthread_mutex_lock()'s implementation, yet they manage to use those functions having only read the documentation. If Boost documentation isn't sufficient for those programmers to use the libraries, then we need to improve the documentation.
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use.
I don't understand why a library is "very dangerous to use" if you can't understand its implementation. That just suggests that you want Boost to be dumbed down for some arbitrarily low experience level.
Tom wasn't talking about completely understanding the code. He just said "some idea what it's doing". And he hasn't suggested to assume some "arbitrarily low experience level".
Really? I wonder how much time he has spent looking at the source for his platform's runtime library. Documentation explains things so you have "some idea what" a library is doing. You don't need to understand the implementation for that.
But I have to admit that it took me significantly longer "than a day" to have "some idea" of how "qt" is working. I definitely agree that it is dangerous to use a library without having "some idea what it's doing". The question whether "qt" is dangerous or not is more complicated. Now "qt" is indeed a bit dangerous, but so is any other reasonable GUI toolkit. But if the choice would be use "qt" or have "no GUI at all", taking the "no GUI at all" option might indeed be significantly less dangerous.
There are many examples of libraries that are difficult to understand -- and even beyond the abilities of many programmers -- but that doesn't mean they aren't usable.
OK, now I drifted off a bit. My point is that I really have to disagree with your statement "I don't understand why a library is "very dangerous to use" if you can't understand its implementation." Denying the need for quality is not a good response if somebody suggests you might have quality problems.
Perhaps I've enlightened you. At any rate, I never denied "the need for quality." I merely said that one needn't understand a library's implementation to make good use of it. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Hi, ----- Original Message ----- From: "Tom Brinkman" <reportbase2007@gmail.com> To: <Boost@lists.boost.org> Sent: Tuesday, March 23, 2010 7:11 PM Subject: [boost] 5 Observations - My experience with the boost libraries
Over the past years, every project that I have been involved with has tried and then either abandoned boost or highly restricted its use.
As a long time boost user, I can't tell you how much debate we've had about this.
I want boost to succeed, grow and be successful. Its sad. As someone who has used boost from the beginning, and has taken far more than I have given, here are some of my observations.
Many of the reasons don't have specifically to do with boost, but more have to do with a preference for one programming style versus another.
I have identified 5 key issues about why boost was abandoned.
1) Boost uses exceptions. 2) Printf versus Iostream. 3) Dependencies. 4) Research Projects 5) Macros
1) Boost uses exceptions.
This issue is best illustrated when you want to just do something as simple as converting a "string" to an "int". boost::numeric_cast throws an exception, which forces you to wrap it into a try-catch block.
The seemingly trivial issue of how to handle exceptions causes endless grief. It seems that developers still prefer "C" style casts.
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
int value = 0; try {value = boost::numeric_cast<int>("3.00");}catch (...){}
versus
int value = atoi("3.00");
I think the lesson is that there is no correct answer here. As most "C++" projects use some "C" libraries, you will need to be flexible in your approach to exception handling. A pure "C++" approach of try-catch blocks is not practical.
As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe.
Small issue, but is undoubtably a source of a huge amount of problems.
I think that C++ developers need to understand how exceptions works. If you dont 't reach any member of your team understand correctly that you should compile without exception support.
2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style.
This issue has been the source of many hours of needless debate. Pure C++ developers seem to have a aversion to "printf" style arguments. As there are very few pure C++ projects (if any), I dont hear about this as much as I once did. Most C/C++ developers prefer a printf style api.
Boost needs to start providing printf style api's.
Boost needs to be more practical. By not also providing printf style api's, boost is not meeting the needs of developers.
Iostream may be preferable for purely academic reasons, but for practical reason, "printf" is the api style that is universally adopted.
Iostream stry is safe. I have worked on a lot of projects having a lot of bug in printf like functions on site. I prefer the compiler give me these kind of errors for safety purposes.
Is it boosts goal to meet only the needs of a small subset of its c++ users? If that is the goal, than it needs be clearly stated as such.
As most developers have adopted a combined C/C++ style of development, a pure academic C++ style syntax is not practical for every day use.
I don't agree Boost goal is to provide any C/C++ developer could use. I see Boost as a collection of libraries that show how people can use the high level C++ language and not only the low level.
Boost needs to look at what the popular api styles are and adopt them and not be so dogamtic about its style of so-called pure "C++".
I will not say pure "C++", just practical C++.
3) Dependencies.
Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't.
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
Do you mean that you dont use any library that uses Boost, any product that uses Boost? I think that your or your leader are following a wrong reasoning. You can forbid the direct use if you have good reason, but I dont see why forbid the use of products that use this Boost library. I don't know which libraries you dont want any member of your project to use and why, could you tell us more?
This issue may seem trivial, but it is the cause endless hourse of grief.
It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost.
I think that this is an educational issue. If you have a good reason to not use a library you should be able to share this with the developers.
For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries.
Could you talk about the obious reason?
The way boost was developed makes this practically impossible.
Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community.
Currently, boost provides the best place to do that, but it needs to be honest with its users.
Boost is what the Boost community want Boost to be. If more people want other style of programming, they can make concrete proposals, participate on the reviews, showing how they think Boost must be.
4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible.
Could you give some examples of research projects?
This is universally considered a good thing and it is always interesting to see what the best and brightest are up too.
Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs.
You are right. Any booster works hard to provide wht he thinks is his day to day needs.
Experience proves otherwise.
The practical needs of large scale active projects are in conflict.
Could you be more explicit. Which needs are in conflict?
Boost is very dogmatic and encourages a particalular style of development, which is very template based.
Templates allows to program using the generic paradigm, and Boost make use of this quite often. Which style of developement would you want?
In the right hands, a heavy templated based project can work.
In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design.
Well it is think quite different to make a generic library that using it. You don't need to spend many more iterations to use a generic library.
It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear.
The fact you have not succeded do not menas that other have not succeed.
That being said, boost::mpl and boost::spririt are wonderful accomplishments
and I use them regularly.
Here there are two examples of the most complex libraries in Boost, and surely betwenn the more useful on a given context.
5) Macros.
Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable.
I know there are practical reasons to use them.
The main reason being compiler inadequacies.
However, many developers question the value of a cutting-edge template library that is full of macros.
For most of the cases the use of PP is to emulate variadic templates. So this is temporary until all the compilers will support variadic templates. Let me say, for 2015.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
What is the practical value of a library that can only be maintained by the original developer(s)?
I don't think this is true. Any Boost library can be maintained by some other than the author. Of course this will need a deep understanding of what and how this is done. I have used a lot of C libraries, and I will need also quite a lot of time to maintain the library. I think that any entrepise using C++ and Boost should have a C++ expert that guide the complete team to adhere to the best practices. This people could be the one that could maintain the library if the author don't do that.
This issue has surprised many, but has comes up often.
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
I expect to have an idea of what a library is doing by reading its documentation, not examining its code. If a library is not enough documented we shoudl make requests to the documentation. Best, Vicente
Iostream may be preferable for purely academic reasons, but for practical
reason, "printf" is the api style that is universally adopted.
Iostream stry is safe. I have worked on a lot of projects having a lot of bug in printf like functions on site. I prefer the compiler give me these kind of errors for safety purposes.
Its not about what you and i prefer. Its all about what is the prevailing standard. Popular techniques are developed over many years. Printf is a popular technique that C++ libraries should continue to support. No reason to abandon it.
I think that your or your leader are following a wrong reasoning. You can forbid the direct use if you have good reason, but I dont see why forbid the use of products that use this Boost library. I don't know which libraries you dont want any member of your project to use and why, could you tell us more?
More than a few boost libraries are considered junk. I wont name names. In any event, it may disconcerting to some to include any of these "junk" libraries into their project. As boost lacks a way to remove those projects, some project leads my deceide to just not use boost at all.
4) Many boost libraries seem more like they research projects. The
prevailing view is that boost libraries push the envelope of what is possible.
Could you give some examples of research projects?
I'm not going to identify individual projects. But there are many that could accurately be described as "academic".
However, many developers question the value of a cutting-edge template library that is full of macros.
For most of the cases the use of PP is to emulate variadic templates. So this is temporary until all the compilers will support variadic templates. Let me say, for 2015.
Good point.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
What is the practical value of a library that can only be maintained by the original developer(s)?
I don't think this is true. Any Boost library can be maintained by some other than the author.
Sorry, not true in practice. Would be nice if that was true.
I expect to have an idea of what a library is doing by reading its documentation, not examining its code. If a library is not enough documented we shoudl make requests to the documentation.
Most developers know that the only real documentation if the source code. Tom Brinkman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/23/2010 05:58 PM, Tom Brinkman wrote:
Iostream may be preferable for purely academic reasons, but for practical
reason, "printf" is the api style that is universally adopted.
Iostream stry is safe. I have worked on a lot of projects having a lot
of bug in printf like functions on site. I prefer the compiler give me these kind of errors for safety purposes.
Its not about what you and i prefer. Its all about what is the prevailing standard. Popular techniques are developed over many years. Printf is a popular technique that C++ libraries should continue to support. No reason to abandon it.
I'm not quite sure I understand the issue here. In what way does boost not "support" printf ? Stefan -- ...ich hab' noch einen Koffer in Berlin...
----- Original Message ----- From: "Tom Brinkman" <reportbase2007@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, March 23, 2010 10:58 PM Subject: Re: [boost] 5 Observations - My experience with the boost libraries
Iostream may be preferable for purely academic reasons, but for practical
reason, "printf" is the api style that is universally adopted.
Iostream stry is safe. I have worked on a lot of projects having a lot of bug in printf like functions on site. I prefer the compiler give me these kind of errors for safety purposes.
Its not about what you and i prefer. Its all about what is the prevailing standard. Popular techniques are developed over many years. Printf is a popular technique that C++ libraries should continue to support. No reason to abandon it.
Please give concrete examples when Boost should use this printf like style.
I think that your or your leader are following a wrong reasoning. You can forbid the direct use if you have good reason, but I dont see why forbid the use of products that use this Boost library. I don't know which libraries you dont want any member of your project to use and why, could you tell us more?
More than a few boost libraries are considered junk. I wont name names.
Please name them. This could improve Boost.
In any event, it may disconcerting to some to include any of these "junk" libraries into their project.
As boost lacks a way to remove those projects, some project leads my deceide to just not use boost at all.
See bcp.
4) Many boost libraries seem more like they research projects. The
prevailing view is that boost libraries push the envelope of what is possible.
Could you give some examples of research projects?
I'm not going to identify individual projects. But there are many that could accurately be described as "academic".
Whithout concrete examples you don't help Boost.
However, many developers question the value of a cutting-edge template library that is full of macros.
For most of the cases the use of PP is to emulate variadic templates. So this is temporary until all the compilers will support variadic templates. Let me say, for 2015.
Good point.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
What is the practical value of a library that can only be maintained by the original developer(s)?
I don't think this is true. Any Boost library can be maintained by some other than the author.
Sorry, not true in practice. Would be nice if that was true.
Note that I have not said that any one can maintain any Boost.Library.
I expect to have an idea of what a library is doing by reading its documentation, not examining its code. If a library is not enough documented we shoudl make requests to the documentation.
Most developers know that the only real documentation if the source code.
Not me. I use to use a lot of Boost libraries and I have just read the documentation and see the examples. If I need to read the code to start using a library there is not a problem with the library code but with the documentation. In this case I think that it is better to request clarifications in the doc. Best, Vicente
Tom Brinkman wrote:
I have identified 5 key issues about why boost was abandoned.
1) Boost uses exceptions. 2) Printf versus Iostream.
Shucks, a hardcore C++ library doesn't cater too well for C programmers!
3) Dependencies.
Agreed, its a mess
4) Research Projects
Yup, agreed.
5) Macros
Well, that's what you get from trying to buil header only solutions with templates when some old-fashioned inheritance would have done. I agree. stlsoft stuff is the same. Personally I much prefer Poco and from what you've said I think you would too - but I find myself wanting ASIO and Botan uses Boost and so does qpid - and to be honest there are useful things like tuple and it can be hard to entirely avoid it.
int value = atoi("3.00");
Except that this is actually a piss-poor example isn't it? - because an input that isn't well formed is not detected by atoi, which is why you have to use strtol and check what the endptr is doing - but no-one every does that right, every time. Which is why exceptions are there.
all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe.
Sure, but its the same ones who use atoi. They probably don't check for EINTR either.
Boost needs to start providing printf style api's.
Try fastformat?
4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible.
This is universally considered a good thing and it is always interesting to see what the best and brightest are up too.
Certainly not universally considered a good thing here, somewhat the opposite. :-( I think maybe Boost should look to partition itself into 'general purpose' libraries and a number of application-oriented libraries, and then look at the stability/maturity within those. But its already fragmented, so there is a possibility to make life even worse here. In many respects I think Boost displays some of the worst aspects of open source development, with a tendency to include things 'because I can and its really clever' rather than 'because you need it to do your mundane little project'. At the end of the day its a volunteer model and they don't actually work as well as a model with leadership, vision - and budget. Which is arguably why qt is in the ascendent now. Perhaps we should all just put principle aside and learn to moc. I do agree with a lot of what you say - but not pleasing C programmers! James
Shucks, a hardcore C++ library doesn't cater too well for C programmers!
Aggreed. Its almost as though some C++ programmers dont even know that "C" exists. Its a pity. There are many things that the typical C++ programmer could learn from the typical C programmer. Not sure it works in reverse though. 3) Dependencies.
Agreed, its a mess
4) Research Projects
Yup, agreed.
5) Macros
Well, that's what you get from trying to buil header only solutions with templates when some old-fashioned inheritance would have done. I agree. stlsoft stuff is the same.
Personally I much prefer Poco and from what you've said I think you would too - but I find myself wanting ASIO and Botan uses Boost and so does qpid - and to be honest there are useful things like tuple and it can be hard to entirely avoid it.
I know, boost has some real gems. Asio is wonderful.
int value = atoi("3.00");
Except that this is actually a piss-poor example isn't it? - because an input that isn't well formed is not detected by atoi, which is why you have to use strtol and check what the endptr is doing - but no-one every does that right, every time. Which is why exceptions are there.
Agreed.
I think maybe Boost should look to partition itself into 'general purpose' libraries and a number of application-oriented libraries, and then look at the stability/maturity within those. But its already fragmented, so there is a possibility to make life even worse here.
Agreed.
In many respects I think Boost displays some of the worst aspects of open source development, with a tendency to include things 'because I can and its really clever' rather than 'because you need it to do your mundane little project'. At the end of the day its a volunteer model and they don't actually work as well as a model with leadership, vision - and budget. Which is arguably why qt is in the ascendent now. Perhaps we should all just put principle aside and learn to moc.
I do agree with a lot of what you say - but not pleasing C programmers!
Agreed.
James
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Zitat von Tom Brinkman <reportbase2007@gmail.com>:
Shucks, a hardcore C++ library doesn't cater too well for C programmers!
Aggreed. Its almost as though some C++ programmers dont even know that "C" exists. Its a pity.
There are many things that the typical C++ programmer could learn from the typical C programmer. Not sure it works in reverse though.
like what? that you should use libraries that were written for the programming language you're using, or expect to do some work on interoperability? you seem to judge C++ libraries by how little C++ features they use. exceptions are standard practice. so is iostreams. there are lots of problems with error codes AND with printf syntax. you had some good points in your original post, like dependencies and library maintainance. but now this turned into complaints that you cannot use a ruby library in a java application without running into problems.
Agreed. I take back the "jab" at C++. I am a C++ programmer. So i felt the a little swipe would be ok. My larger point though is that we C++ developers can use all of "C", but not vice versa. Thats all. On Tue, Mar 23, 2010 at 3:18 PM, <strasser@uni-bremen.de> wrote:
Zitat von Tom Brinkman <reportbase2007@gmail.com>:
Shucks, a hardcore C++ library doesn't cater too well for C programmers!
Aggreed. Its almost as though some C++ programmers dont even know that "C" exists. Its a pity.
There are many things that the typical C++ programmer could learn from the typical C programmer. Not sure it works in reverse though.
like what? that you should use libraries that were written for the programming language you're using, or expect to do some work on interoperability?
you seem to judge C++ libraries by how little C++ features they use.
exceptions are standard practice. so is iostreams. there are lots of problems with error codes AND with printf syntax.
you had some good points in your original post, like dependencies and library maintainance. but now this turned into complaints that you cannot use a ruby library in a java application without running into problems.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman wrote:
There are many things that the typical C++ programmer could learn from the typical C programmer. Not sure it works in reverse though.
How about using the appropriate data structures for the task at hand? OK, I admit that this is challenging without having templates to help you with this. But macros should be able work around this problem. Fixed size buffers, variable size buffers and singly linked lists are extremely overused data structures in typical C code, while C++ code tends to use the appropriate data structures for the task at hand (if they happen to be part of the standard library). Something more practical to learn is to write "constructors" for all your "potentially evolving" data structures, because adding new members to these could otherwise lead to bugs in code using these data structures. So, now it's your turn. Just name one or two of the many things that the typical C++ programmer (me) could learn form the typical C programmer. Regards, Thomas
Tom Brinkman <reportbase2007 <at> gmail.com> writes:
Over the past years, every project that I have been involved with has tried and then either abandoned boost or highly restricted its use.
My general comment to this post is In my personal opinion you are overgeneralize your experience. My experience, while having some common points is rather different in many other aspects.
1) Boost uses exceptions.
This issue is best illustrated when you want to just do something as simple as converting a "string" to an "int". boost::numeric_cast throws an exception, which forces you to wrap it into a try-catch block.
You probably meant lexical_cast.
The seemingly trivial issue of how to handle exceptions causes endless grief.
I must admit I had 1 or 2 instances where I would have welcomed more graceful interface for lexical_cast, but in 99 of other places I use it I expect error to be an error.
It seems that developers still prefer "C" style casts.
Not in my experience and I discourage anyone on my team from using them.
The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required.
Umm... why? Performance?
I think the lesson is that there is no correct answer here. As most "C++" projects use some "C" libraries, you will need to be flexible in your approach to exception handling.
I think the lesson is that exceptions should report *errors*. If you tend to put try/catch around the function invocation, that means interface is incorrectly designed and in some cases you want to deal with error condition right there. I do agree that some of the interfaces we have might exhibit the issue though.
A pure "C++" approach of try-catch blocks is not practical.
try-catch blocks is pure Java approach. In C++ you should not have many of these in your application code.
As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe.
RAII + boost::execution_monitor allows me to avoid most of them.
Small issue, but is undoubtably a source of a huge amount of problems.
2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's".
Not in my experience. I personally dislike all these woodoo strings and strive to stay away from them as far as possible.
Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style.
C++ adopted it long ago. Boost developers follow the suite.
This issue has been the source of many hours of needless debate. Pure C++ developers seem to have a aversion to "printf" style arguments. As there are very few pure C++ projects (if any), I dont hear about this as much as I once did. Most C/C++ developers prefer a printf style api.
Boost needs to start providing printf style api's.
Boost.Format does allow one to use printf like statements. Though unless you have internationalization requirements, I personally do not see a reason to prefer one (I know of course some who do). Otherwise I am not sure what you mean. You need to show specific examples.
Boost needs to be more practical. By not also providing printf style api's, boost is not meeting the needs of developers.
Iostream may be preferable for purely academic reasons, but for practical reason, "printf" is the api style that is universally adopted.
In most of the project I worked for last 10 year we moved away from the printf like api.
3) Dependencies.
Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't.
I think you are overstate the problem. There are number of core components almost definitely required, but there are many many others which can be easily split.
4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible.
You've got couple options as I see it. 1. Don't use these 2. Stick to one version which works and use it. 3. Maintain one yourself. What is not an option *in general* is to tell the library author: "Do not make any changes". That said I concur that we need to have "grading" in boost libraries. Some should be graded as "production-ready", some "in-development", some "candidate". First section is disallowed to make backward incompatible changes and thus cna be safely used in production environments.
Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs.
I do not believe boost pretends to be anything. You can't make this general statement about something being developed in 90 different directions.
Boost is very dogmatic and encourages a particalular style of development, which is very template based.
I do not believe I agree with this statement. At least not in full. I do see some instance of template overuse, but I see many others where templates are right on a spot. It might help if you cna show some concrete examples.
In the right hands, a heavy templated based project can work.
In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design.
It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear.
That being said, boost::mpl and boost::spririt are wonderful accomplishments
If you are using mpl and spirit in your production code I can't see other template use cases to be much more advanced.
and I use them regularly.
5) Macros.
Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable.
Are these macros part of public interface? If yes, that might indicate the issue. Though There are number of reasons why this is the case. Take Boost.Test for example.
However, many developers question the value of a cutting-edge template library that is full of macros.
I am not. I have very good respect to the PP and all that it can do for us.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Definitely not for that reason. The unit tests and documentation should serve this purpose.
What is the practical value of a library that can only be maintained by the original developer(s)?
My (slightly extreme) position is that this is exactly right thing to do. In many cases the amount of work necessary to make the code maintainable by any developer way exceeds the benefits. You document every function and every if statement, describe some implementation decisions and performance considerations and still new guy make some silly mistake. IMO we are putting too much value into implementation. Keep the interface and unit tests, and spend some time to rewrite the whole thing, so that new developer knows it as his 5 fingers. This is not an absolute rule, but makes sense in many circumstances.
This issue has surprised many, but has comes up often.
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
I do not know how most boost libraries I am using work inside. And I sleep well somehow. ;) Gennadiy
Tom Brinkman wrote:
Over the past years, every project that I have been involved with has tried and then either abandoned boost or highly restricted its use.
Interesting. Every project I know is using Boost more intensely every day.
I want boost to succeed, grow and be successful. Its sad. As someone who has used boost from the beginning, and has taken far more than I have given, here are some of my observations.
IMHO, if you have the chance, try to find teams that want to use it and appreciate the high quality you can find here. I am aware that no everybody can choose, but if you can, do it.
Many of the reasons don't have specifically to do with boost, but more have to do with a preference for one programming style versus another.
I have identified 5 key issues about why boost was abandoned.
1) Boost uses exceptions.
Sure, why not? Exceptions make sure that you have to take care of problems. In your atoi example, there is a tremendous risk that developers do not take care of errors.
2) Printf versus Iostream.
And streams are so fantastically cool. Ever since I wrote my first stream operator for some class of mine and serialized some object with it, wow, I never wanted to use printf again. Never.
3) Dependencies.
Yeah, well, code re-use. Of course, it leads to many dependencies but: a) You could restrict yourself to the header-only stuff (no dependency trouble at all) b) You could use tools like ldd (linux) or whatever Windows offers to look at the dependencies. It is pretty easy actually To be honest, I don't mind the dependencies at all. It would be a pretty bad sign if no boost library would depend on others. In some cases, I would prefer even more code re-use. For instance, the DateTime classes could use spirit for parsing and formatting. They did not, when I looked last. And they are much slower than they could be...
4) Research Projects
Hmm? I don't think so. And even if it were true, well, then don't use the ones you don't like. What's the problem? I am certainly not using all of them. But the number of boost libraries I am using is growing, and I would not want to live without the ones I am using.
5) Macros
Yup, I don't like them, too. But one of the really cool things about boost is the platform independence. As a result, when you use Boost, you don't have to care about platform specific stuff (most of the time), because all the ugly stuff is hidden behind the curtains of Boost. To sum it up: IMHO, your 5 points are either invalid (research) or actually pretty cool :-) Regards, Roland
Tom Brinkman wrote:
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
What is the practical value of a library that can only be maintained by the original developer(s)?
This issue has surprised many, but has comes up often.
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
Tom Brinkman
Tom, I disagree with the underlying principle of this argument, and I want to expand on why. For some reason, people believe that because Boost comes with source code, they can only use it if they can both read the source and maintain it. This strikes me as contrary to the whole idea of a library. To my understanding, the reason to use a library is that the underlying problem either is too cumbersome to allow for a new solution to be built in a reasonable time, or because the solution contains some set of subtle pitfalls that will lead a new development to make errors that will not be obvious to diagnose or fix. In such a case, you off load the work and specialized understanding needed to someone else, and use what they produce. When using a library of any sort, there should be a limit to the blind trust applied. You should combine whatever tests are provided with the library along with tests created in house to assess the suitability of the library for the intended use. If the library passes all the tests you come up with that address your needs, and it passes the tests that the developers came up with to address their vision of t=what it should do, then you are assured that it is at least as good as anything you would develop in house. So, you use it. Only if it fails at providing some identified need do you need to worry about how to modify it and maintain it. (Almost all software does fail, sooner or later, but until it does there is nothing to fix.) If it is failing before you even try to use it, you contact the developer and try to work toward improvement. If it happens to be simple, you can try to modify it yourself, but this is always a dangerous course of action. After you create in house modifications that your program depends on, you have cut yourself off from all of the future development of the library without a potentially large later development and merge effort. So, it is almost always better to work with the providers of the library to get your requested fixes to be a part of the future releases instead of making them independently and hoping they will be compatible with future releases from a provider who knows nothing of your changes. In general, this is a case of relying on knowing the internal implementation of the library, instead of depending on the provided interface. Almost no software promises anything about the details of the internal implementation from one release to the next, and it is almost always foolish to assume you know what it will be. That means, good development practice implies that you never plan to provide maintenance for a third party library wholly in house. So, any argument that starts from wanting to provide it in house is already starting from bad practice. From that foundation, it has no persuasive power. The truth is, third party libraries are tools provided by someone else. When I use tools provided by someone else, I have a responsibility to test them to generate reasonable assurance that they fulfill my needs, and to work with a source that I think will be responsible in those cases where new flaws are exposed. This is no different from using closed source third party tools such as some of the Intel numerical libraries, or the MS compilers. I might be able to hack the binaries to do what I want (I work for a company that provides tools for analyzing binaries and for modifying them, so this is possible. It is just unlikely to work right.), but I would be making a mistake to try. If I don't think Intel or MS are responsible enough to work with me when flaws are discovered, then I should find ways not to use their tools. If I use their tools, then I am committed to working with them to remediate flaws, and I do not expect to be able to fix them independently, nor do I think it would be a good course of action to do so if I could. So, a valid argument would be to say you don't think the Boost developers would be responsible about trying to address problems you exposed. If you believe that to be true, then that is a major problem with Boost that we really do need to address. John
Thanks John. Well, for the most part, I agree with the larger point that you have made. However, for some reason, people don't apply that same standard to boost. Because boost is open-source, the source code is obviously available so people will invariably take a peak at it. If what they see scares them, and then they find out that the library may in fact have only one one active maintainer, it can be a real source of concern. Its strange though, because MPL is the most difficult to understand library of them all, but in the view of many it is boost's most important and valuable contribution. I think that we all have made an exception for that library, considering its overall importance. Others probably feel the same for some of the other core boost libraries. Because they are so important, they would get fixed eventually, by someone other than the core developer, if it ever became necessary. Its all the other non-core boost libraries that people worry about. A big complex template laden library, in a non-critical vertical, with only one active maintainer, in source code that appears to be completely unmaintainable. These secondary boost libraries are the concern. For me, its not a big deal. I know what the core libraries are. However, if your not an active boost user, you wont be able to identify what these core libraries are, so you just get worried about boost as a whole. The solution, as expressed on this forum many times, is to somehow seperate out the core libraries from the non-core libraries. Tom Brinkman
On Tue, Mar 23, 2010 at 10:11 PM, Tom Brinkman <reportbase2007@gmail.com> wrote:
If what they see scares them, and then they find out that the library may in fact have only one one active maintainer, it can be a real source of concern.
My view has always been that you should never look at source code, only at documentation. If that's not enough to use the library, post a bug report.
The solution, as expressed on this forum many times, is to somehow seperate out the core libraries from the non-core libraries.
We have the same high standards applied to all libraries that are admitted in Boost. There are no second grade citizens here. Also, what's a secondary library for me might be the only reason for someone else to use Boost. If there is anything that could help, that is to reduce coupling in all Boost libraries. That, I think, is impossible at this point in time. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
We have core libs and we have sugar around it.
Agreed. We just need to be honest about that fact. Otherwise, some may just dismiss all of boost. On Thu, Mar 25, 2010 at 3:31 PM, Markus Werle <numerical.simulation@web.de> wrote:
Emil Dotchevski wrote:
We have the same high standards applied to all libraries that are admitted in Boost. There are no second grade citizens here.
I disagree here. We have core libs and we have sugar around it.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 3/24/2010 1:11 AM, Tom Brinkman wrote:
Thanks John.
Well, for the most part, I agree with the larger point that you have made.
However, for some reason, people don't apply that same standard to boost. Because boost is open-source, the source code is obviously available so people will invariably take a peak at it.
If what they see scares them, and then they find out that the library may in fact have only one one active maintainer, it can be a real source of concern.
Its strange though, because MPL is the most difficult to understand library of them all, but in the view of many it is boost's most important and valuable contribution. I think that we all have made an exception for that library, considering its overall importance. Others probably feel the same for some of the other core boost libraries. Because they are so important, they would get fixed eventually, by someone other than the core developer, if it ever became necessary.
Its all the other non-core boost libraries that people worry about. A big complex template laden library, in a non-critical vertical, with only one active maintainer, in source code that appears to be completely unmaintainable.
This was a point I made in another thread. From the end-user perspective a Boost library is great as long as the feeling that there is someone maintaining the library exists. I do not worry about the internal complexity of a Boost library as long as the documentation is good enough to allow me as an end-user to use it. I think there are Boost libraries where the original author of the library, for very understandable reasons, no longer actively maintains it or is responsive to problems, bugs, suggested improvements for the library. In that case I think it is important that someone else take over maintenance of a Boost library. It is way too onerous to expect even the good C++ programmer to have to understand a Boost library internally to be able to use it. That's why it is important that someone is actually still maintaining a Boost library even if the problems regarding it may be small to virtually non-existent. As for who might be willing to take over maintenance of someone else's Boost library I think there are enough skillful people who follow Boost that if there were a policy by which a new maintainer were to be looked for when an original author of a library no longer wishes to maintain it, another person would be found. I can not imagine a developer willing to maintian a library forever but I can imagine others willing to maintain it during its realistic usage period. That's why I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library. I think that even currently there are a number of Boost libraries where the original author pays little to no attention to it or attempts to fix bugs, address problems, and listen to suggestions regarding the library, and it would be wise for Boost to transfer "ownership" of the library to somebody else.
On Wed, Mar 24, 2010 at 11:26 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
That's why I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library.
Why do we need an official policy if someone has to volunteer anyway? It's not like there's an army of volunteers and we have to be careful to pick the right candidate. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Wed, 2010-03-24 at 11:57 -0700, Emil Dotchevski wrote:
On Wed, Mar 24, 2010 at 11:26 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
That's why I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library.
Why do we need an official policy if someone has to volunteer anyway? It's not like there's an army of volunteers and we have to be careful to pick the right candidate. :)
It isn't always clear to what extent an original maintainer is still actively supporting a library, especially because tickets will still automatically get assigned to them in trac. Sometimes they'll still fix the occasional bug, but the rest of the TODO list will just sit there, and if they had a way to say "if anyone else would like to take this over, I'm mostly working on other things", it might encourage possibly-qualified list-lurkers (like me!) to volunteer more, even if it's just default ownership of reported problems. I don't know how formal it should be, but I think having a way for a maintainer to admit that they've mostly moved on might be a good thing. Jim Bosch
I don't know how formal it should be, but I think having a way for a
Jim Bosch wrote: maintainer to admit that they've mostly moved on might be a good thing. Is there some 'activity metric' or some other way of measuring if the library is being maintained or neglected? That might be a way to programmatically show volunteers where attention is needed even in the absence of the maintainer admitting they've moved on. Erik
What exactly is the policy on library ownership. I forgot. What does the boost license say anyways. Does it say somewhere that a library is 'owned' by an individual and not by boost. Why cant anyone on the approved boost developer list make changes to any of the libraries they want. There is a audit trail, it could be subsequently removed, if warrented. On Wed, Mar 24, 2010 at 12:20 PM, Nelson, Erik - 2 <erik.l.nelson@bankofamerica.com> wrote:
Jim Bosch wrote:
I don't know how formal it should be, but I think having a way for a maintainer to admit that they've mostly moved on might be a good thing.
Is there some 'activity metric' or some other way of measuring if the library is being maintained or neglected? That might be a way to programmatically show volunteers where attention is needed even in the absence of the maintainer admitting they've moved on.
Erik _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 3/24/2010 2:57 PM, Emil Dotchevski wrote:
On Wed, Mar 24, 2010 at 11:26 AM, Edward Diener<eldiener@tropicsoft.com> wrote:
That's why I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library.
Why do we need an official policy if someone has to volunteer anyway? It's not like there's an army of volunteers and we have to be careful to pick the right candidate. :)
Because there are libraries of which questions are asked, bug reports are written, and suggestions are made which get absolutely no response from the person who is the author/maintainer of the library. If none of the Boost leaders pay any attention to this situation then the feeling by end-users that a library is not really being supported will continue and people will stop using that library. If Boost had some sort of policy by which authors/maintainers of a library, who are no longer paying any attention to it in response to Boost users, get relieved of the responsibility of supporting the library and someone else is chosen to maintain it instead, it would be good for the end-users and for Boost developers as well. Of course this would mean that whatever "rights" once a library is submitted to Boost ( I am not a legal expert ) which the author of a Boost library retains can be removed if the author does not support the library any longer, and that this is part of Boost policy.
On 24 March 2010 19:37, Edward Diener <eldiener@tropicsoft.com> wrote:
If none of the Boost leaders pay any attention to this situation then the feeling by end-users that a library is not really being supported will continue and people will stop using that library.
Boost leaders?
If Boost had some sort of policy by which authors/maintainers of a library, who are no longer paying any attention to it in response to Boost users, get relieved of the responsibility of supporting the library and someone else is chosen to maintain it instead, it would be good for the end-users and for Boost developers as well.
IMO it'd be better if a group of people took over, for a higher bus factor. I would put the library into maintenance i.e. no major changes. Any new features could be developed separately and then proposed on the list (not necessarily a formal review). I'm not sure if it should be formalised though, circumstances might different for different components.
Of course this would mean that whatever "rights" once a library is submitted to Boost ( I am not a legal expert ) which the author of a Boost library retains can be removed if the author does not support the library any longer, and that this is part of Boost policy.
The boost license is pretty clear. There's no need to remove any rights, ownership isn't as formal as you think. It's mostly based on respect and convention. http://www.boost.org/LICENSE_1_0.txt Daniel
On 3/24/2010 4:17 PM, Daniel James wrote:
On 24 March 2010 19:37, Edward Diener<eldiener@tropicsoft.com> wrote:
If none of the Boost leaders pay any attention to this situation then the feeling by end-users that a library is not really being supported will continue and people will stop using that library.
Boost leaders?
There is no need to pretend that there are not Boost developers whom others think of as the leaders of Boost. While no one may officially be considered a "leader" surely there are those who are looked up to as such.
If Boost had some sort of policy by which authors/maintainers of a library, who are no longer paying any attention to it in response to Boost users, get relieved of the responsibility of supporting the library and someone else is chosen to maintain it instead, it would be good for the end-users and for Boost developers as well.
IMO it'd be better if a group of people took over, for a higher bus factor. I would put the library into maintenance i.e. no major changes. Any new features could be developed separately and then proposed on the list (not necessarily a formal review). I'm not sure if it should be formalised though, circumstances might different for different components.
A group of people could be fine also. I just feel that when current maintainers of libraries are no longer responding to requests and queries regarding that library that someone has to take the responsibility of seeing if another person, or group of people, can maintain the library better. I am not trying to downplay the enormous work and expertise needed to develop a library accepted into Boost in any way. I am just trying to be realistic in that a programmer may have other interests in his life which preclude the time necessary to pay attention to his Boost library(s). At the same time there are many Boost libraries which hardly need any more done with them so any large additions to the library may better be served by a new library by someone else. This has already been done ( such as with signals and signals2 ) and I see nothing wrong with this model.
Of course this would mean that whatever "rights" once a library is submitted to Boost ( I am not a legal expert ) which the author of a Boost library retains can be removed if the author does not support the library any longer, and that this is part of Boost policy.
The boost license is pretty clear. There's no need to remove any rights, ownership isn't as formal as you think. It's mostly based on respect and convention.
The license is one thing and even the "Library Maintainer's Rights and Responsibilities" which Steve Watanabe links to in another post is another, but unless someone with authority decides that library X, being ignored by the maintainer, needs to be taken over by another who is amenable to fixes and changes, it is not going to happen. The main reason is somewhat psychological. If an end-user complains that maintainer X is not responding to requests about library X it will be seen as a derogatory put down of maintainer X. If a boost developer complains it may also be seen as a form of competitive envy. Despite your objection to Boost "leaders" someone has to take the bit between the teeth in order to effect change.
On 24 March 2010 21:11, Edward Diener <eldiener@tropicsoft.com> wrote:
On 3/24/2010 4:17 PM, Daniel James wrote:
Boost leaders?
There is no need to pretend that there are not Boost developers whom others think of as the leaders of Boost. While no one may officially be considered a "leader" surely there are those who are looked up to as such.
If you wait for them to deal with your issues, you'll be waiting a long time. Daniel
Edward Diener wrote:
he license is one thing and even the "Library Maintainer's Rights and Responsibilities" which Steve Watanabe links to in another post is another, but unless someone with authority decides that library X, being ignored by the maintainer, needs to be taken over by another who is amenable to fixes and changes, it is not going to happen. The main reason is somewhat psychological. If an end-user complains that maintainer X is not responding to requests about library X it will be seen as a derogatory put down of maintainer X. If a boost developer complains it may also be seen as a form of competitive envy. Despite your objection to Boost "leaders" someone has to take the bit between the teeth in order to effect change.
I think you propose not the best way to approach the problem of abandoned libraries. Suppose there's a formal procedure of taking over. Like, an email is posted saying: Library X is unmaintained. If you would like to take maintenance over, and fix the 50 bugs currently filed against it, and also fix all new bugs, step forward. Do you expect many people will volunteer? On the other hand, if fixing a bug in library X does *not* require any formal process and takes 5 minutes, it's much more likely that bugs will be fixed. I think we need to have an official "it's ok to apply patches everywhere" policy more than anything else. - Volodya
Sounds good. Nice and loose. On Wed, Mar 24, 2010 at 3:02 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Edward Diener wrote:
he license is one thing and even the "Library Maintainer's Rights and Responsibilities" which Steve Watanabe links to in another post is another, but unless someone with authority decides that library X, being ignored by the maintainer, needs to be taken over by another who is amenable to fixes and changes, it is not going to happen. The main reason is somewhat psychological. If an end-user complains that maintainer X is not responding to requests about library X it will be seen as a derogatory put down of maintainer X. If a boost developer complains it may also be seen as a form of competitive envy. Despite your objection to Boost "leaders" someone has to take the bit between the teeth in order to effect change.
I think you propose not the best way to approach the problem of abandoned libraries. Suppose there's a formal procedure of taking over. Like, an email is posted saying:
Library X is unmaintained. If you would like to take maintenance over, and fix the 50 bugs currently filed against it, and also fix all new bugs, step forward.
Do you expect many people will volunteer? On the other hand, if fixing a bug in library X does *not* require any formal process and takes 5 minutes, it's much more likely that bugs will be fixed. I think we need to have an official "it's ok to apply patches everywhere" policy more than anything else.
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, 2010-03-25 at 01:02 +0300, Vladimir Prus wrote:
Edward Diener wrote:
he license is one thing and even the "Library Maintainer's Rights and Responsibilities" which Steve Watanabe links to in another post is another, but unless someone with authority decides that library X, being ignored by the maintainer, needs to be taken over by another who is amenable to fixes and changes, it is not going to happen. The main reason is somewhat psychological. If an end-user complains that maintainer X is not responding to requests about library X it will be seen as a derogatory put down of maintainer X. If a boost developer complains it may also be seen as a form of competitive envy. Despite your objection to Boost "leaders" someone has to take the bit between the teeth in order to effect change.
I think you propose not the best way to approach the problem of abandoned libraries. Suppose there's a formal procedure of taking over. Like, an email is posted saying:
Library X is unmaintained. If you would like to take maintenance over, and fix the 50 bugs currently filed against it, and also fix all new bugs, step forward.
Do you expect many people will volunteer? On the other hand, if fixing a bug in library X does *not* require any formal process and takes 5 minutes, it's much more likely that bugs will be fixed. I think we need to have an official "it's ok to apply patches everywhere" policy more than anything else.
I think distributed, decentralized bug-fixing is exactly the right model - for bug fixing - and I think that's all most stable boost libraries need. And honestly, even the libraries which don't seem to be getting much attention don't seem to have much in the way of serious bugs. There are a few that could do with more active, intrusive development, however (even if it's just to make the library more interoperable with newer boost libraries), and I think that might require a small group of people who are actually in charge of where that library goes in the future. Maybe all that's needed is a review process for proposed major updates to a library. Perhaps it would be better to have a commitment to re-reviewing existing libraries every N years, so the whole community can get involved, review-style, on where a library should go next. Jim Bosch
On 3/24/2010 6:02 PM, Vladimir Prus wrote:
Edward Diener wrote:
he license is one thing and even the "Library Maintainer's Rights and Responsibilities" which Steve Watanabe links to in another post is another, but unless someone with authority decides that library X, being ignored by the maintainer, needs to be taken over by another who is amenable to fixes and changes, it is not going to happen. The main reason is somewhat psychological. If an end-user complains that maintainer X is not responding to requests about library X it will be seen as a derogatory put down of maintainer X. If a boost developer complains it may also be seen as a form of competitive envy. Despite your objection to Boost "leaders" someone has to take the bit between the teeth in order to effect change.
I think you propose not the best way to approach the problem of abandoned libraries. Suppose there's a formal procedure of taking over. Like, an email is posted saying:
Library X is unmaintained. If you would like to take maintenance over, and fix the 50 bugs currently filed against it, and also fix all new bugs, step forward.
Do you expect many people will volunteer? On the other hand, if fixing a bug in library X does *not* require any formal process and takes 5 minutes, it's much more likely that bugs will be fixed. I think we need to have an official "it's ok to apply patches everywhere" policy more than anything else.
Has the fixing of bugs in the manner you cite above worked so far ? ( rhetorical question ) Aside from bugs being fixed or doc being updated, what happens when people request changes to be made, whether additions or updates to the current functionality ? Meanwhile the people who have taken over maintenance of neglected libraries seem to have done a very good job. They have much more at stake than the occasional fixer of a bug in some library. As far as people volunteering if the leading Boost developers were to ask for somebody taking over a library which has been neglected by the original author, yes I think someone who is interested in doing so will volunteer. One does not need "many people". One just needs a single person who has the time and pride in their programming excellence to do so. But even if it does not happen for some particular library where not a single person is willing to take over maintenance of the library, the fact that Boost has asked for someone to come forward clarifies the fact that the library has been abandoned by its originator and random people might be more willing to help out and fix bugs in that library knowing that.
Edward Diener wrote:
On 3/24/2010 6:02 PM, Vladimir Prus wrote:
more likely that bugs will be fixed. I think we need to have an official "it's ok to apply patches everywhere" policy more than anything else.
Has the fixing of bugs in the manner you cite above worked so far ? ( rhetorical question )
It does for most other big open source projects. Boost is IMVHO a bit overly courteous to the maintainer/author, which as a result means that there are fewer "junior maintainers".
Aside from bugs being fixed or doc being updated, what happens when people request changes to be made, whether additions or updates to the current functionality ?
Do it with fast ad hoc review, but with reversed sign, if nobody objects its in. Regards Fabio
Yes, yes. Do that. Propose that to group. On Thu, Mar 25, 2010 at 12:23 AM, Fabio Fracassi <f.fracassi@gmx.net> wrote:
Edward Diener wrote:
On 3/24/2010 6:02 PM, Vladimir Prus wrote:
more likely that bugs will be fixed. I think we need to have an official "it's ok to apply patches everywhere" policy more than anything else.
Has the fixing of bugs in the manner you cite above worked so far ? ( rhetorical question )
It does for most other big open source projects. Boost is IMVHO a bit overly courteous to the maintainer/author, which as a result means that there are fewer "junior maintainers".
Aside from bugs being fixed or doc being updated, what happens when people request changes to be made, whether additions or updates to the current functionality ?
Do it with fast ad hoc review, but with reversed sign, if nobody objects its in.
Regards
Fabio
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Fabio Fracassi wrote:
Edward Diener wrote:
Has the fixing of bugs in the manner you cite above worked so far ? ( rhetorical question )
It does for most other big open source projects. Boost is IMVHO a bit overly courteous to the maintainer/author, which as a result means that there are fewer "junior maintainers".
Aside from bugs being fixed or doc being updated, what happens when people request changes to be made, whether additions or updates to the current functionality ?
Do it with fast ad hoc review, but with reversed sign, if nobody objects its in.
In case it's not obvious, I'd like to point out a user's perspective on your considerations. When I look for C++ code, I look at Boost libraries first. I expect it to have gone through a careful review process before being accepted. I expect to find solutions to any problems or bugs that I may run into. And I expect the most useful libraries to make their way eventually into a C++ standard. I don't expect the same quality from open source code. That doesn't mean that it can't be as good, just that I am more wary of an open source project that I have never used. Once a Boost library is accepted, it relies on developers to maintain its quality at the same level it had, when Boost accepted it. If there is no longer someone to take on that responsibility, I don't think I can rely on it the same way I used to. Again, that doesn't mean it that can't have the same quality, just that I should be wary of fixes and changes. If a library no longer has a responsible maintainer, I would like to see a caveat warning attached to it. It would tell me that I should expect the same level of quality as any other open source project. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Wednesday, March 24, 2010 8:17 PM To: boost@lists.boost.org Subject: Re: [boost] 5 Observations - My experience with the boost libraries
Of course this would mean that whatever "rights" once a library is submitted to Boost ( I am not a legal expert ) which the author of a Boost library retains can be removed if the author does not support the library any longer, and that this is part of Boost policy.
The boost license is pretty clear. There's no need to remove any rights, ownership isn't as formal as you think. It's mostly based on respect and convention.
IANAL ;-) But I am clear that the legal status of Boost, a worldwide organisation, is extremely ill defined. So nobody has any effective 'rights' except perhaps those of copyright law (which varies widely). What the license means is the nobody else has the right to *stop* anyone else doing anything with the code. They can sell it, but they can't stop anyone else selling it, or using it. (Unless they manage to patent it - probably tricky). Boost runs almost entirely based on respect and convention, so we should avoid going all 'lawyerish' :-) If the maintainer appears missing (on holiday even), I'd favour quicker patching of bugs, after some discussion seeking agreement - or veto. I think this works already, but slowly, perhaps we need to be a little less concerned for authors 'rights'. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
If the maintainer appears missing (on holiday even), I'd favour quicker patching of bugs, after some discussion seeking agreement - or veto.
This would be a really bad idea in my opinion - for more than one reason. Very often, what users characterise as "bugs" are really one of the following: * error in user's code * misunderstanding of error / warning messages * result of choices made by the developers in the course of making tradeoffs between legimate optoins. * intentional features of the design which are not appreciated by the "fixer" In summary, many of the proposed "bug fixes" are not bugs but something else and the proponent doesn't understand this. almost all changes have or can have unexpected side effects in places totally unexpected by the naive maintainer. Most of the boost libraries address a huge number of issues "under the covers". (That's what libraries are for) Most of these fixes/patches are untested. The proponent thinks he's tested them because the "fix" made his program work. But that's in no way the same a running the test suite on all platformas and build variants. The above are good reasons for running changes through a maintainer. But the real reason is: The current system makes one person responsable for maintaining any given library and gives that person the autority required to accept that responsability. Once you give others the authority to mess with a library - the maintainer cannot be held responsable for it's state. Now that he's been handed an impossible task - he'll just move on. Result - no maintainer. Robert Ramey
On Thu, Mar 25, 2010 at 10:25 AM, Robert Ramey <ramey@rrsd.com> wrote:
Paul A. Bristow wrote:
If the maintainer appears missing (on holiday even), I'd favour quicker patching of bugs, after some discussion seeking agreement - or veto. ... In summary, many of the proposed "bug fixes" are not bugs but something else and the proponent doesn't understand this.
I think this would be dealt with adequately by a "non-missing" maintainer (e.g. responsive), who would close out, or reclassify the nonsensical tickets. I believe the key here is the lack of responsiveness by the maintainer. Jon
Jonathan Franklin <franklin.jonathan <at> gmail.com> writes:
I believe the key here is the lack of responsiveness by the maintainer.
We need to be careful, how we identify this lack of responsiveness. Maybe we should ask maintainer to acknowledge that he seen the ticket? The fact that ticket is not addressed is not an indicator that maintainer is not aware about it. Gennadiy
On Thu, Mar 25, 2010 at 10:42 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
We need to be careful, how we identify this lack of responsiveness. Maybe we should ask maintainer to acknowledge that he seen the ticket? The fact that ticket is not addressed is not an indicator that maintainer is not aware about it.
I agree. And I'm not sure how to properly measure "responsiveness." Perhaps some ratio of tickets closed to tickets opened over time (or *something*) would provide a usable metric for determining when a maintainer is overwhelmed, or just not doing anything at all. Jon
----- Original Message ----- From: "Jonathan Franklin" <franklin.jonathan@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, March 25, 2010 5:51 PM Subject: Re: [boost] Library Maintainence - was 5 Observations ....
On Thu, Mar 25, 2010 at 10:42 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
We need to be careful, how we identify this lack of responsiveness. Maybe we should ask maintainer to acknowledge that he seen the ticket? The fact that ticket is not addressed is not an indicator that maintainer is not aware about it.
I agree. And I'm not sure how to properly measure "responsiveness."
Perhaps some ratio of tickets closed to tickets opened over time (or *something*) would provide a usable metric for determining when a maintainer is overwhelmed, or just not doing anything at all.
Even whan the the maintainer does a good work, there could also hapens that there could be yet a lot of tickets or very old tikets to manage. This could be an hint that maintenance need to be reinforced. Vicente
----- Original Message ----- From: "Gennadiy Rozental" <rogeeff@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, March 25, 2010 5:42 PM Subject: Re: [boost] Library Maintainence - was 5 Observations ....
Jonathan Franklin <franklin.jonathan <at> gmail.com> writes:
I believe the key here is the lack of responsiveness by the maintainer.
We need to be careful, how we identify this lack of responsiveness. Maybe we should ask maintainer to acknowledge that he seen the ticket?
Ye sthis is the idea. We ned to kwno if the ticket is on the hands of the maintainer.
The fact that ticket is not addressed is not an indicator that maintainer is not aware about it.
If the maintainer is aware of a ticket that is open since a long time, maybe it is time for the the maintainer to request the help of a co-maintainer. Vicente
At Thu, 25 Mar 2010 16:42:01 +0000 (UTC), Gennadiy Rozental wrote:
Jonathan Franklin <franklin.jonathan <at> gmail.com> writes:
I believe the key here is the lack of responsiveness by the maintainer.
We need to be careful, how we identify this lack of responsiveness. Maybe we should ask maintainer to acknowledge that he seen the ticket? The fact that ticket is not addressed is not an indicator that maintainer is not aware about it.
The system has an “accepted” state for tickets precisely so that a maintainer can note that he has it in his queue. This is the way it's /supposed/ to work (IMO): * Unreviewed tickets are assigned to the default maintainer, but not accepted or commented on by him * Reviewed tickets are either accepted or reassigned to someone else -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
Robert Ramey <ramey <at> rrsd.com> writes:
Paul A. Bristow wrote:
If the maintainer appears missing (on holiday even), I'd favour quicker patching of bugs, after some discussion seeking agreement - or veto.
This would be a really bad idea in my opinion - for more than one reason.
I must say I agree with all of the Robert points. With "live" author/maintainer it should his or her responsibility to accept and/or apply patches/fixes. For libraries with no maintainer around we either can obtain "communal" responsibility - which is not good IMO in almost all the cases or assign new maintainer, which might be acceptable but is not ideal IMO. The best approach IMO is to deprecate library immediately in next release, announce "contest" and "winner"/volunteer will rewrite library with the same API using the same unit tests (may or may not use existing implementation). If all the unit tests pass as a result, I do not see a need even for another review. Library reinstated in it's rights immediately. Gennadiy
----- Original Message ----- From: "Gennadiy Rozental" <rogeeff@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, March 25, 2010 5:29 PM Subject: Re: [boost] Library Maintainence - was 5 Observations ....
Robert Ramey <ramey <at> rrsd.com> writes:
Paul A. Bristow wrote:
If the maintainer appears missing (on holiday even), I'd favour quicker patching of bugs, after some discussion seeking agreement - or veto.
This would be a really bad idea in my opinion - for more than one reason.
I must say I agree with all of the Robert points. With "live" author/maintainer it should his or her responsibility to accept and/or apply patches/fixes.
I agree. But atleast the maintainer should respond to the requests in a reasonable time. Currently there are a lot of requests that are completly ignored if you don't insist quite often. See for example the report at <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&order=changetime&col=id&col=summary&col=component&col=status&col=type&col=owner&col=severity&col=changetime&type=!Feature+Requests>
For libraries with no maintainer around we either can obtain "communal" responsibility - which is not good IMO in almost all the cases or assign new maintainer, which might be acceptable but is not ideal IMO. The best approach IMO is to deprecate library immediately in next release, announce "contest" and "winner"/volunteer will rewrite library with the same API using the same unit tests (may or may not use existing implementation). If all the unit tests pass as a result, I do not see a need even for another review. Library reinstated in it's rights immediately.
I don't think that a new maintainer will reimplement the library completly at least not immediately. If the library pass already all the unit test, the library will be reinstated de facto. The problem is that we dont have unit tests to test the whether the ticket is a BUG or not. Vicente
AMDG Robert Ramey wrote:
This would be a really bad idea in my opinion - for more than one reason.
Very often, what users characterise as "bugs" are really one of the following:
* error in user's code * misunderstanding of error / warning messages * result of choices made by the developers in the course of making tradeoffs between legimate optoins. * intentional features of the design which are not appreciated by the "fixer"
In summary, many of the proposed "bug fixes" are not bugs but something else and the proponent doesn't understand this.
almost all changes have or can have unexpected side effects in places totally unexpected by the naive maintainer.
As someone who does periodically apply fixes to unmaintained libraries, I completely agree with this statement. Writing a good patch is generally not a trivial task. I think I'm pretty meticulous and I still make mistakes sometimes. In Christ, Steven Watanabe
AMDG Edward Diener wrote:
Because there are libraries of which questions are asked, bug reports are written, and suggestions are made which get absolutely no response from the person who is the author/maintainer of the library. If none of the Boost leaders pay any attention to this situation then the feeling by end-users that a library is not really being supported will continue and people will stop using that library. If Boost had some sort of policy by which authors/maintainers of a library, who are no longer paying any attention to it in response to Boost users, get relieved of the responsibility of supporting the library and someone else is chosen to maintain it instead, it would be good for the end-users and for Boost developers as well. Of course this would mean that whatever "rights" once a library is submitted to Boost ( I am not a legal expert ) which the author of a Boost library retains can be removed if the author does not support the library any longer, and that this is part of Boost policy.
We do have a policy--no one pays any attention to it though. http://www.boost.org/community/reviews.html#Maintainer In Christ, Steven Watanabe
Emil Dotchevski wrote:
On Wed, Mar 24, 2010 at 11:26 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
That's why I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library.
Why do we need an official policy if someone has to volunteer anyway? It's not like there's an army of volunteers and we have to be careful to pick the right candidate. :)
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil, I think where we need to consider an official policy is on the other end. In the current structure of Boost, the author of the library has control of it unless they explicitly cede that control. So, if a developer disappears, no one feels they have the right to mess with the library. We need to change the expectations on that count. So, developers submitting libraries to Boost do so with the understanding that a substantial period of inactivity while there are issues that need to be addressed means that someone else is allowed (and expected) to step in and become the prime maintainer. Inaction cedes control by default. In my opinion, this is an important issue for Boost and I place it is more important than many of Tom's original points. John
On 3/24/2010 9:01 PM, John Phillips wrote:
Emil Dotchevski wrote:
On Wed, Mar 24, 2010 at 11:26 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
That's why I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library.
Why do we need an official policy if someone has to volunteer anyway? It's not like there's an army of volunteers and we have to be careful to pick the right candidate. :)
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil,
I think where we need to consider an official policy is on the other end. In the current structure of Boost, the author of the library has control of it unless they explicitly cede that control. So, if a developer disappears, no one feels they have the right to mess with the library.
We need to change the expectations on that count. So, developers submitting libraries to Boost do so with the understanding that a substantial period of inactivity while there are issues that need to be addressed means that someone else is allowed (and expected) to step in and become the prime maintainer. Inaction cedes control by default.
I agree with this as a general point and I think that if there is any dismay by users of Boost libraries it is because there is a feeling with certain libraries that the original developer is no longer around to deal with issues and nobody else has been empowered to take over. So if there are problems when dealing with such a Boost library the end-user may feel that he is too much on his own to solve them, or to figure out how to effectively do certain things with the library which the documentation does not make clear enough. Other than that, from this user's viewpoint, I can not understand programming groups which do not give the C++ developer the right to use Boost libraries as he deems fit. The libraries are of such high quality, and the documentation is generally good enough, that any really competent C++ programmer can save enormous amounts of time and write much more elegant and understandable code using Boost libraries than otherwise.
Edward Diener wrote:
I agree with this as a general point and I think that if there is any dismay by users of Boost libraries it is because there is a feeling with certain libraries that the original developer is no longer around to deal with issues and nobody else has been empowered to take over.
Empowering has never been a problem. Finding a qualified volunteer is.
Edward Diener wrote:
On 3/24/2010 1:11 AM, Tom Brinkman wrote:
Thanks John.
As for who might be willing to take over maintenance of someone else's Boost library I think there are enough skillful people who follow Boost that if there were a policy by which a new maintainer were to be looked for when an original author of a library no longer wishes to maintain it, another person would be found.
I think that for maintainance chores we do not need an owner/maintainer, but should simply allow anyone interested enough (who has "earned" svn access) to just fix them. Many big Open Source projects work this way, most even collect/mark issues that they want "newbees" to fix. Patches are usually send to the devel list and reviewd by one or more of the regulars. Someone who managed to get 2-3 patches commited will usually be given commit rights, and can then start to bring in more people. I think by giving maintainance to a group of people greatly lowers the barrier of entry into the community. regards Fabio
On Mar 24, 2010, at 2:26 PM, Edward Diener wrote:
I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library.
Great! Can you start a new thread that gives a detailed proposal for the policy, so we have something to work with? -- David Abrahams BoostPro Computing http://boostpro.com
On 3/24/2010 9:31 PM, David Abrahams wrote:
On Mar 24, 2010, at 2:26 PM, Edward Diener wrote:
I am suggesting that Boost create some sort of policy so that maintenance of an actively used Boost library be transferred to others whenever the original library author(s) no longer wish to maintain the library.
Great! Can you start a new thread that gives a detailed proposal for the policy, so we have something to work with?
I do not have a detailed proposal, nor do I think one is needed. Just explain to those submitting libraries to Boost that if they no longer support their library under Boost the maintenance of the library will be offered to someone else who wishes to support and maintain it. By support it can be explained as a willingness to fix bugs, update docs if they deem it necessary and possibly add or extend features if it is apropos to what the library was originally intended to do. I do not think that delineating exactly what support of a library by a developer means is going to help anyone. I take it that Boost developers are smart enough to know when they are no longer supporting their library, and that quite a few developers may indeed liike the fact that when they get tired of supporting their library someone else will take it over.
Tom Brinkman wrote:
However, for some reason, people don't apply that same standard to boost. Because boost is open-source, the source code is obviously available so people will invariably take a peak at it.
If what they see scares them, and then they find out that the library may in fact have only one one active maintainer, it can be a real source of concern.
This week I was in trouble for having written code my boss does not understand. Admittedly, the boss has never written a line in C++, but looking at the code he was "shocked", as he said. IMHO I did not even use too much template stuff, but it was a C++/CLI bridge using bind/foreach/ref_ptr/etc. and I had to work around compiler bugs ... [another story OT] There always is a tradeoff between features/maintainability of code and ease of understanding. Those who want it all but do not want to pay for it, please go away and write maintenance nightmares in C#. I have colleagues who do not understand the meaning of keyword const and why it may be a good idea to qualify methods as such. It's the same debate, only on a much lower level. I have to defend myself for writing parsers using boost::spirit, because colleagues are not well educated and do not want to take the extra time to read the docs and learn about EBNF. Drawing the conclusion that boost is bad, since I cannot convince my job mates, is odd to me. No, I will not write a parser with if-then-else anymore. We hacked a full-featured asynchronous serial line communication steering controller hardware with 2-way communication and 3 levels of serial line message parsing and inteligent error handling within 4 days using asio for the first time in our life. Is boost bad because my boss has problems while staring at the source code of asio? I cannot follow you in any aspect. Could you please give an example where using a boost library did not pay off and where the effort invested was in vain? The whole discussion reminds me of Salieri talking about Mozart's music as "having too many notes". What we need is education. My kids should learn modern C++ before they get 17 years old. We need managers who know their mass from a black hole. All this: problems beyond boost. Markus
Markus Werle wrote:
Could you please give an example where using a boost library did not pay off and where the effort invested was in vain?
Did any of you ever realized that this question is not fair? (Even rhetorical questions should try to stay fair.) Do you really think that any of us wants to openly blame a boost library like you propose, especially knowing that the author has put a lot of effort into it, and is in principle still around? Yes, there was such a boost library. Instead of naming it directly, I will describe the issues it had. If you recognice the library, good for you, but please don't tell the name. 1) "operator=" shouldn't have unexpected behavior. What is unexpected behavior with respect to "operator="? One possible implementation of "operator=" can be found at <http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/>: T& operator=(T x) // x is a copy of the source; hard work already done { swap(*this, x); // trade our resources for x's return *this; // our (old) resources get destroyed with x } An implementation of "operator=" that has a significant different semantics from this is unexpected. I think the above "operator=" would even be correct for "auto_ptr", so I really believe that this statement contains some truth. 2) Don't inherit from concrete classes. This is something much more subtle and actually quite an iteresting lesson I learned from this practical example. One of my collegues tried to educate me about this before, but I couldn't understand why he thought this would be important. It's a bit tricky to explain without showing actual code and its concrete issues. The mentioned boost library provided a sort of container, but there was no "swap" functionality. I tried to add one (among others to enable me to write "operator=" in the canonical way), but soon found out that this won't work out well, because of the inheritance hierarchy using concrete classes. 3) A significant runtime overhead for some common tasks and a TODO item in the documentation to investigate this and find out whether it can be fixed. I guess I already said much too much, but I wanted to really make it clear and concrete that this question is not fair, so here we are now. Regards, Thomas
Tom Brinkman wrote:
1) Boost uses exceptions.
I am not surprised. Boost was written in *modern* C++. Exceptions are such a central concept in modern C++ you cannot really get around it. Take the chance to get deterministic code using RAII with exceptions and proper stack unwinding. Something I really like a lot. Maybe the whole point is not about boost but about modern C++ being disliked by those who never had the chance to get known to its advantages ...
As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code.
Not true. I have a 65000 LOC project (GUI, numerics, 3D plots) where I thought of exceptions right from the beginning. There are about 15 catch clauses, 2 which I really need, the rest due to compiler issues or lazy quick hacks added later. Q: What is wrong with try-catch blocks all over your code? Markus
I use exceptions too and like them. My point was rather, there is not the option to not use them, and there is no policy about their usage. This always comes back to bite you. On Thu, Mar 25, 2010 at 3:53 PM, Markus Werle <numerical.simulation@web.de> wrote:
Tom Brinkman wrote:
1) Boost uses exceptions.
I am not surprised. Boost was written in *modern* C++. Exceptions are such a central concept in modern C++ you cannot really get around it.
Take the chance to get deterministic code using RAII with exceptions and proper stack unwinding. Something I really like a lot.
Maybe the whole point is not about boost but about modern C++ being disliked by those who never had the chance to get known to its advantages ...
As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code.
Not true. I have a 65000 LOC project (GUI, numerics, 3D plots) where I thought of exceptions right from the beginning. There are about 15 catch clauses, 2 which I really need, the rest due to compiler issues or lazy quick hacks added later.
Q: What is wrong with try-catch blocks all over your code?
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Mar 25, 2010 at 6:58 PM, Tom Brinkman <reportbase2007@gmail.com>wrote:
1) Boost uses exceptions.
I'm a game programmer. I've worked at companies that disable exceptions. One advantage of exceptions is that when they occur, the stack is unwound and object destructors are executed. Another is that higher-level code is given an opportunity to recover from the exceptional condition. If you don't care about either of these things, it might be acceptable for your program to terminate at any point where it would normally throw an exception. Assuming your C++ implementation already terminates execution or otherwise behaves acceptably when features like std::operator new and reference dynamic_cast fail with exceptions disabled, I think you could achieve that with Boost using the preprocessor as shown below. #ifndef THROW_H #define THROW_H #include <cstdlib> struct Throw { }; template< class T > inline void operator <<( Throw &, T const & ) { std::exit( EXIT_FAILURE ); } #define throw Throw() << #endif You would include "Throw.h" before any headers that throw exceptions, perhaps using a compiler's force-include feature. You could compile the non-header-only Boost libraries with this, too. You could overload operator << to do different things with different exceptions, such as reporting the error in some fashion, or using platform specific code to detect if a debugger is attached and break if so. This would also have the advantage that it would to some extent allow your C++ programmers to use exception semantics in their own code. If you come across cases where you don't want to terminate, and you're very clever and lucky, you might be able to make operator << translate the exception into a return value for the function. This would be difficult because the same exception could be thrown by functions with different return value types. You could return a Throw & from operator << and add conversion operators to Throw to make it turn into whatever the function wants. However, it would be difficult to know what an appropriate return value would be. I think this simple header could allow Boost to be used in an environment that frowns on exceptions without any changes to Boost. Of course, I haven't tried any of it. Nick
Of course, I didn't consider the problem of exception specifications. You'd have to do something fancy to work around that. Nick On Sun, Mar 28, 2010 at 1:38 PM, Nicholas Howe <nicholas.howe@gmail.com>wrote:
On Thu, Mar 25, 2010 at 6:58 PM, Tom Brinkman <reportbase2007@gmail.com>wrote:
1) Boost uses exceptions.
I'm a game programmer. I've worked at companies that disable exceptions. One advantage of exceptions is that when they occur, the stack is unwound and object destructors are executed. Another is that higher-level code is given an opportunity to recover from the exceptional condition. If you don't care about either of these things, it might be acceptable for your program to terminate at any point where it would normally throw an exception. Assuming your C++ implementation already terminates execution or otherwise behaves acceptably when features like std::operator new and reference dynamic_cast fail with exceptions disabled, I think you could achieve that with Boost using the preprocessor as shown below.
#ifndef THROW_H #define THROW_H
#include <cstdlib>
struct Throw { };
template< class T > inline void operator <<( Throw &, T const & ) { std::exit( EXIT_FAILURE ); }
#define throw Throw() <<
#endif
You would include "Throw.h" before any headers that throw exceptions, perhaps using a compiler's force-include feature. You could compile the non-header-only Boost libraries with this, too. You could overload operator << to do different things with different exceptions, such as reporting the error in some fashion, or using platform specific code to detect if a debugger is attached and break if so. This would also have the advantage that it would to some extent allow your C++ programmers to use exception semantics in their own code.
If you come across cases where you don't want to terminate, and you're very clever and lucky, you might be able to make operator << translate the exception into a return value for the function. This would be difficult because the same exception could be thrown by functions with different return value types. You could return a Throw & from operator << and add conversion operators to Throw to make it turn into whatever the function wants. However, it would be difficult to know what an appropriate return value would be.
I think this simple header could allow Boost to be used in an environment that frowns on exceptions without any changes to Boost. Of course, I haven't tried any of it. Nick
Nicholas Howe <nicholas.howe <at> gmail.com> writes:
On Thu, Mar 25, 2010 at 6:58 PM, Tom Brinkman <reportbase2007 <at>
gmail.com>wrote:
1) Boost uses exceptions.
I'm a game programmer. I've worked at companies that disable exceptions.
[...]
#ifndef THROW_H #define THROW_H
#include <cstdlib>
struct Throw { };
template< class T > inline void operator <<( Throw &, T const & ) { std::exit( EXIT_FAILURE ); }
#define throw Throw() <<
#endif
[...]
There's already BOOST_THROW_EXCEPTION to allow users some degree of adaptability when throwing an exception inside a Boost library: http://www.boost.org/libs/exception/doc/BOOST_THROW_EXCEPTION.html However, BOOST_THROW_EXCEPTION does not assume that the function throwing can return more or less normally: the user can only specify a termination procedure. Besides, it's not clear to me what the degree is of adoption of this macro in place of raw throw across Boost libraries. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On 03/28/2010 11:38 AM, Nicholas Howe wrote:
On Thu, Mar 25, 2010 at 6:58 PM, Tom Brinkman<reportbase2007@gmail.com>wrote:
1) Boost uses exceptions.
I'm a game programmer. I've worked at companies that disable exceptions.
I've worked at companies that disable exceptions, and, with little exception, the rules were put in place by programmers that didn't understand exceptions at all. My experience suggests that these people should be ignored. Don't waste time on this red herring. This is 2010. Exceptions are an important part of the language. One cannot write non-trivial code that guarantees behavior without them. Calling std::exit() from a library is the absolute worst thing that one can do. Rob
Tom Brinkman wrote:
3) Dependencies.
its practically impossible to isolate the ones you want from from the ones you don't.
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
I agree we have a dependency jungle problem within boost.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
OTOH if the great benefit of using some boost library is not obvious to the project lead and the lead "screws" it just because of defects within the SD process (no review?) and team communication isssues then the lead should change and not boost.
This issue may seem trivial, but it is the cause endless hourse of grief.
It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost.
AFAICS there are not too many C++ libraries around that can compete those in boost. Most of the times the boost version is superior. So "if in doubt, take it from boost" is probably a GoodThing. I do not see a problem here.
For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries.
I prefer a pragmatic approach here: Grab something from the internet, try to use it, check if library is actively maintained and estimate the chance this will be so for a while. If it works, make a code review and if no issues are risen, go on to the next problem.
The way boost was developed makes this practically impossible.
Come on: a) Install a wiki on the intranet (5 to 55 minutes, depending on OS) b) copy the list of libraries from http://www.boost.org/doc/libs (3 minutes) c) add allowed/disallowed tags to all of them (1h, further discussions later) d) send email to team with link to wiki page (5 minutes) e) kill people during code review who do not adopt the rules (1 second) What kind of project leads are you working with?
Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community.
No. Most boost libraries are pre-stage for an industry standard. No one is pretending here. They are serious about this.
Currently, boost provides the best place to do that, but it needs to be honest with its users.
4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible.
This is universally considered a good thing and it is always interesting to see what the best and brightest are up too.
Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs.
For me that is exactly what boost does.
Experience proves otherwise.
Not for me.
The practical needs of large scale active projects are in conflict.
Boost is very dogmatic and encourages a particalular style of development, which is very template based.
Modern C++. Yes. Not less than that for good reasons.
In the right hands, a heavy templated based project can work.
No. That is not the point. Templates are used in order to obtain an extremely high level of abstraction while not sacrificing performance. Something like Solver.AddPDE(ddt(rho) + ddx(rho*u) == 0); where the PDE is disasembled at compile time (!) and all its components are differentiated with regard to all variables again at compile time and the solver solves the problem within the theoretically achieveable minimum time.
In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design.
Proof is missing here. Could you please rewrite boost::spirit without templates? Could you please rewrite boost::function without templates? Could you please rewrite boost::lambda without templates?
It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear.
Boost libraries or code outside of boost? Again my impression: it is more an issue of Modern C++ vs. Baby C++
That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly.
So fear depends on author?
5) Macros.
Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable.
I know there are practical reasons to use them.
The main reason being compiler inadequacies.
However, many developers question the value of a cutting-edge template library that is full of macros.
Value comes from usability. Do you judge a car by how you can drive it or not? Platform independence has its price. If you do not want to pay for it, then ... shrug.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Maximum Portability. Usability. Performance.
What is the practical value of a library that can only be maintained by the original developer(s)?
This issue has surprised many, but has comes up often.
Good Point. There are efforts to collect all the dirty tricks. A good start is: http://www.amazon.com/exec/obidos/ASIN/0201734842/ http://www.artima.com/cppsource/foreach.html
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
I do not get this. It never takes more than an hour to get the key point of a boost library after reading the docs. C++ is not Knuth literal programming. Markus
What kind of project leads are you working with?
The best. <wink>
Boost libraries or code outside of boost? Again my impression: it is more an issue of Modern C++ vs. Baby C++
Yeah, that pretty much sums it up. On Thu, Mar 25, 2010 at 4:37 PM, Markus Werle <numerical.simulation@web.de> wrote:
Tom Brinkman wrote:
3) Dependencies.
its practically impossible to isolate the ones you want from from the ones you don't.
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
I agree we have a dependency jungle problem within boost.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
OTOH if the great benefit of using some boost library is not obvious to the project lead and the lead "screws" it just because of defects within the SD process (no review?) and team communication isssues then the lead should change and not boost.
This issue may seem trivial, but it is the cause endless hourse of grief.
It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost.
AFAICS there are not too many C++ libraries around that can compete those in boost. Most of the times the boost version is superior. So "if in doubt, take it from boost" is probably a GoodThing. I do not see a problem here.
For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries.
I prefer a pragmatic approach here: Grab something from the internet, try to use it, check if library is actively maintained and estimate the chance this will be so for a while. If it works, make a code review and if no issues are risen, go on to the next problem.
The way boost was developed makes this practically impossible.
Come on:
a) Install a wiki on the intranet (5 to 55 minutes, depending on OS) b) copy the list of libraries from http://www.boost.org/doc/libs (3 minutes) c) add allowed/disallowed tags to all of them (1h, further discussions later) d) send email to team with link to wiki page (5 minutes) e) kill people during code review who do not adopt the rules (1 second)
What kind of project leads are you working with?
Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community.
No. Most boost libraries are pre-stage for an industry standard. No one is pretending here. They are serious about this.
Currently, boost provides the best place to do that, but it needs to be honest with its users.
4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible.
This is universally considered a good thing and it is always interesting to see what the best and brightest are up too.
Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs.
For me that is exactly what boost does.
Experience proves otherwise.
Not for me.
The practical needs of large scale active projects are in conflict.
Boost is very dogmatic and encourages a particalular style of development, which is very template based.
Modern C++. Yes. Not less than that for good reasons.
In the right hands, a heavy templated based project can work.
No. That is not the point. Templates are used in order to obtain an extremely high level of abstraction while not sacrificing performance.
Something like
Solver.AddPDE(ddt(rho) + ddx(rho*u) == 0);
where the PDE is disasembled at compile time (!) and all its components are differentiated with regard to all variables again at compile time and the solver solves the problem within the theoretically achieveable minimum time.
In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design.
Proof is missing here.
Could you please rewrite boost::spirit without templates? Could you please rewrite boost::function without templates? Could you please rewrite boost::lambda without templates?
It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear.
Boost libraries or code outside of boost? Again my impression: it is more an issue of Modern C++ vs. Baby C++
That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly.
So fear depends on author?
5) Macros.
Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable.
I know there are practical reasons to use them.
The main reason being compiler inadequacies.
However, many developers question the value of a cutting-edge template library that is full of macros.
Value comes from usability. Do you judge a car by how you can drive it or not?
Platform independence has its price. If you do not want to pay for it, then ... shrug.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Maximum Portability. Usability. Performance.
What is the practical value of a library that can only be maintained by the original developer(s)?
This issue has surprised many, but has comes up often.
Good Point. There are efforts to collect all the dirty tricks. A good start is: http://www.amazon.com/exec/obidos/ASIN/0201734842/ http://www.artima.com/cppsource/foreach.html
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
I do not get this. It never takes more than an hour to get the key point of a boost library after reading the docs. C++ is not Knuth literal programming.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear.
That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly.
So fear depends on author?
No, I just no khow many times I have re-written my own designs. Its just so god-damn hard to get right. Those that do, my hats off to them. On Thu, Mar 25, 2010 at 4:37 PM, Markus Werle <numerical.simulation@web.de> wrote:
Tom Brinkman wrote:
3) Dependencies.
its practically impossible to isolate the ones you want from from the ones you don't.
What does this mean?
Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't.
I agree we have a dependency jungle problem within boost.
Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all.
OTOH if the great benefit of using some boost library is not obvious to the project lead and the lead "screws" it just because of defects within the SD process (no review?) and team communication isssues then the lead should change and not boost.
This issue may seem trivial, but it is the cause endless hourse of grief.
It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost.
AFAICS there are not too many C++ libraries around that can compete those in boost. Most of the times the boost version is superior. So "if in doubt, take it from boost" is probably a GoodThing. I do not see a problem here.
For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries.
I prefer a pragmatic approach here: Grab something from the internet, try to use it, check if library is actively maintained and estimate the chance this will be so for a while. If it works, make a code review and if no issues are risen, go on to the next problem.
The way boost was developed makes this practically impossible.
Come on:
a) Install a wiki on the intranet (5 to 55 minutes, depending on OS) b) copy the list of libraries from http://www.boost.org/doc/libs (3 minutes) c) add allowed/disallowed tags to all of them (1h, further discussions later) d) send email to team with link to wiki page (5 minutes) e) kill people during code review who do not adopt the rules (1 second)
What kind of project leads are you working with?
Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community.
No. Most boost libraries are pre-stage for an industry standard. No one is pretending here. They are serious about this.
Currently, boost provides the best place to do that, but it needs to be honest with its users.
4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible.
This is universally considered a good thing and it is always interesting to see what the best and brightest are up too.
Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs.
For me that is exactly what boost does.
Experience proves otherwise.
Not for me.
The practical needs of large scale active projects are in conflict.
Boost is very dogmatic and encourages a particalular style of development, which is very template based.
Modern C++. Yes. Not less than that for good reasons.
In the right hands, a heavy templated based project can work.
No. That is not the point. Templates are used in order to obtain an extremely high level of abstraction while not sacrificing performance.
Something like
Solver.AddPDE(ddt(rho) + ddx(rho*u) == 0);
where the PDE is disasembled at compile time (!) and all its components are differentiated with regard to all variables again at compile time and the solver solves the problem within the theoretically achieveable minimum time.
In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design.
Proof is missing here.
Could you please rewrite boost::spirit without templates? Could you please rewrite boost::function without templates? Could you please rewrite boost::lambda without templates?
It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear.
Boost libraries or code outside of boost? Again my impression: it is more an issue of Modern C++ vs. Baby C++
That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly.
So fear depends on author?
5) Macros.
Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable.
I know there are practical reasons to use them.
The main reason being compiler inadequacies.
However, many developers question the value of a cutting-edge template library that is full of macros.
Value comes from usability. Do you judge a car by how you can drive it or not?
Platform independence has its price. If you do not want to pay for it, then ... shrug.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
Maximum Portability. Usability. Performance.
What is the practical value of a library that can only be maintained by the original developer(s)?
This issue has surprised many, but has comes up often.
Good Point. There are efforts to collect all the dirty tricks. A good start is: http://www.amazon.com/exec/obidos/ASIN/0201734842/ http://www.artima.com/cppsource/foreach.html
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries.
I do not get this. It never takes more than an hour to get the key point of a boost library after reading the docs. C++ is not Knuth literal programming.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 23 March 2010 14:11, Tom Brinkman <reportbase2007@gmail.com> wrote:
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use.
What about, for example, compression or security libs? I don't know how libjpeg works. I couldn't explain bz2's text compression scheme. I have no interest in the details of H.264 codecs. I can't tell you what encryption scheme SSL uses. Does that mean I shouldn't use any of them? Very often the whole point of using the libraries is that you don't know how they do what they do, since you don't want to and shouldn't have to. I'm really not worried that I would get lost in a chip layout diagram for all the hundreds of millions of transistors in my processor.
All valid points. These are good points to use when you get some push back to using a complicate, otherwise hard to explain and understand library. I just get quiet and shrug my shoulders. On Thu, Mar 25, 2010 at 4:54 PM, Scott McMurray <me22.ca+boost@gmail.com> wrote:
On 23 March 2010 14:11, Tom Brinkman <reportbase2007@gmail.com> wrote:
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use.
What about, for example, compression or security libs? I don't know how libjpeg works. I couldn't explain bz2's text compression scheme. I have no interest in the details of H.264 codecs. I can't tell you what encryption scheme SSL uses. Does that mean I shouldn't use any of them?
Very often the whole point of using the libraries is that you don't know how they do what they do, since you don't want to and shouldn't have to.
I'm really not worried that I would get lost in a chip layout diagram for all the hundreds of millions of transistors in my processor. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Good one, Scott ;-) Yeah, I also thought that some of the idea of sustainable software was to, well, modularize code and distinguish interface from implementation... /David On Mar 25, 2010, at 7:54 PM, Scott McMurray wrote:
On 23 March 2010 14:11, Tom Brinkman <reportbase2007@gmail.com> wrote:
If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use.
What about, for example, compression or security libs? I don't know how libjpeg works. I couldn't explain bz2's text compression scheme. I have no interest in the details of H.264 codecs. I can't tell you what encryption scheme SSL uses. Does that mean I shouldn't use any of them?
Very often the whole point of using the libraries is that you don't know how they do what they do, since you don't want to and shouldn't have to.
I'm really not worried that I would get lost in a chip layout diagram for all the hundreds of millions of transistors in my processor. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (36)
-
Daniel James -
David Abrahams -
David Bergman -
Edward Diener -
Emil Dotchevski -
Fabio Fracassi -
Gennadiy Rozental -
James Mansion -
Jim Bosch -
Joaquin M Lopez Munoz -
Joel Falcou -
John Phillips -
Jonathan Franklin -
Lubomir Bourdev -
Markus Werle -
Mathias Gaunard -
Matus Chochlik -
Nelson, Erik - 2 -
Nevin Liber -
Nicholas Howe -
Paul A. Bristow -
Peter Dimov -
Rene Rivera -
Richard Hadsell -
Rob Riggs -
Robert Ramey -
Roland Bock -
Scott McMurray -
Stefan Seefeld -
Steven Watanabe -
Stewart, Robert -
strasser＠uni-bremen.de -
Thomas Klimpel -
Tom Brinkman -
vicente.botet -
Vladimir Prus