This is not a full review, mainly because I have not had the time to devote more than a quick glance over the documentation (which is a good read, btw). Upfront my vote: no, please do not include this library into Boost. My reasons are: a) Boost is a library which has quite some visibility not only for library writers but also for application developers. IMHO, Boost not only has the task of finding new ways for using C++, but it plays the role of evangelizing good programming style, great API design, and thoughtful functionality. Using macros as the sole API of a library to be mainly used by application writers (not library authors) is not a good idea because of all those well know problems related to macros: difficult to debug, error messages are even more difficult to interpret than those generated by TMP, macros are type agnostic and have absolutely no knowledge of C++, etc. b) The proposed library does not add any functionality which couldn't be _easily_ replaced by using existing C++ language features or libraries. This is especially true if we talk about C++11 (which we should, IHMO). c) A very personal reason: code written based on the proposed library for me tends to be an unreadable mess. I have problems to remember, what arguments to the macros means what, when to use additional parenthesis and when not, etc. This is especially true when it comes to using 'default' and 'bind' in the argument list. This just does not 'look right' to me. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On Fri, Nov 18, 2011 at 6:41 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
This is not a full review, mainly because I have not had the time to devote more than a quick glance over the documentation (which is a good read, btw).
Hello Hartmut, thank you very much for your comments. I hope you will have the time to submit a full review (especially now that the end date has been extended) because some of the comments you make are more about general programming styles and macro usage than about specific aspects of Boost.Local.
Upfront my vote: no, please do not include this library into Boost.
My reasons are:
a) Boost is a library which has quite some visibility not only for library writers but also for application developers. IMHO, Boost not only has the task of finding new ways for using C++, but it plays the role of evangelizing good programming style, great API design, and thoughtful functionality. Using macros as the sole API of a library to be mainly used by application writers (not library authors) is not a good idea because of
However, there are many other Boost libraries that use a macro API to save the application writes from writing boiler-plate code (Boost.ScopeExit, Boost.ForEach, ... I am sure the list is longer maybe someone can reply with the complete list here). Why should we threat Boost.Local differently in this respect?
all those well know problems related to macros: difficult to debug, error messages are even more difficult to interpret than those generated by TMP,
Boost.Local macros are comparable in debug and error message complexity to the macros used by Boost.ScopeExit. In this case, the macros are only used in the function declaration so the compiler-errors fully support you as usual in correcting your function definition code (which is where most of the complexity of the function is). I personally find Boost.ScopeExit macros as well as Boost.Local macros easy to use. Did you have issues in using either one of these macros?
macros are type agnostic and have absolutely no knowledge of C++, etc.
Why is this "type agnostic" and "absolutely no knowledge of C++" a problem for Boost.Local? Can you provide an example so I can understand your point better?
b) The proposed library does not add any functionality which couldn't be _easily_ replaced by using existing C++ language features or libraries. This
With respect to other libraries, there is no other Boost library (and no other library in general at least that I know of) that allows you to write local functions while retaining statement syntax for the function definition.
is especially true if we talk about C++11 (which we should, IHMO).
It is true that if you have C++11 lambdas you will probably use those over Boost.Local closures. However, if you need to write code that works on both C++11 and C++03 and performs like C++11 lambdas on C++11, Boost.Local helps you there.
c) A very personal reason: code written based on the proposed library for me tends to be an unreadable mess. I have problems to remember, what arguments to the macros means what, when to use additional parenthesis and when not, etc. This is especially true when it comes to using 'default' and 'bind' in the argument list. This just does not 'look right' to me.
I put a lot of effort in making the macro syntax as natural as possible based on many comments from Boosters. Do you really find this code hard to follow? If so why? int max = 0; bool BOOST_LOCAL_FUNCTION_PARAMS(int x, const bind max) { return x < a; } BOOST_LOCAL_FUNCTION_NAME(small) small(10); Of course, I am asking for you honest and unbiased opinion :) (If default is really such a big deal then I can just avoid providing default parameters for local functions. But honestly I don't think that having a syntax you get used to within ~1week for an optional feature like default local function parameters is really the point, is it?) Thank you very much for your comments and I hope you will have more time to write a full review of Boost.Local. --Lorenzo
Le 19/11/2011 01:18, Lorenzo Caminiti a écrit :
However, there are many other Boost libraries that use a macro API to save the application writes from writing boiler-plate code
Most of them are there to emulate a now C++11 facility or even better actually pushed for the same C+11 facility.
With respect to other libraries, there is no other Boost library (and no other library in general at least that I know of) that allows you to write local functions while retaining statement syntax for the function definition.
The problem is that there is no need for C++ local function IMHO.
It is true that if you have C++11 lambdas you will probably use those over Boost.Local closures. However, if you need to write code that works on both C++11 and C++03 and performs like C++11 lambdas on C++11, Boost.Local helps you there.
C++03 is C++03, could be good for everybody if the C++11 bandwagon was jumped on by more people. Havign boost starting to provide C++11 based library could be the bootstrap C++11 require. Bootstrap that will ensure compiler vendors care about the new standard.
int max = 0; bool BOOST_LOCAL_FUNCTION_PARAMS(int x, const bind max) { return x< a; } BOOST_LOCAL_FUNCTION_NAME(small) small(10);
just using phoenix and/or lambda : int max = 0; auto small = _1 < max; local functions could be nice fi you have huge ones. One liners becomes nightmares and if you have a huge local function, make it a function.
On Wed, Nov 23, 2011 at 5:06 AM, Joel Falcou <joel.falcou@gmail.com> wrote:
Le 19/11/2011 01:18, Lorenzo Caminiti a écrit :
However, there are many other Boost libraries that use a macro API to save the application writes from writing boiler-plate code
Most of them are there to emulate a now C++11 facility or even better actually pushed for the same C+11 facility.
Can you be more specific? Which macros are to emulate C++11 facilities and which ones are not? For example, ScopeExit is not (macro are not to emulate a C++11 facility, they are just for boiler-plate).
With respect to other libraries, there is no other Boost library (and no other library in general at least that I know of) that allows you to write local functions while retaining statement syntax for the function definition.
The problem is that there is no need for C++ local function IMHO.
OK, that goes to the core of the issue IMO. Others have expressed a different opinion in their reviews but I understand and respect your opinion.
It is true that if you have C++11 lambdas you will probably use those over Boost.Local closures. However, if you need to write code that works on both C++11 and C++03 and performs like C++11 lambdas on C++11, Boost.Local helps you there.
C++03 is C++03, could be good for everybody if the C++11 bandwagon was jumped on by more people. Havign boost starting to provide C++11 based library could be the bootstrap C++11 require. Bootstrap that will ensure compiler vendors care about the new standard.
IMO it's a matter of time. Some tool chains (in my personal case GCC based) need to be certified by 3rd parties (suppliers, etc) before they can be used in some production code. It just takes time for every supplier involved in the process to deal with the latest rev pushed out by the compiler vendor. At the end of that process is the application developer that finally gets the "ok, you can now use gcc with C++11 on". That is just my own experience, others might have different degrees of freedom in their ability to adopt their latest compiler rev. I'm putting the following into context:
c) A very personal reason: code written based on the proposed library for me tends to be an unreadable mess. I have problems to remember, what arguments to the macros means what, when to use additional parenthesis and when not, etc. This is especially true when it comes to using 'default' and 'bind' in the argument list. This just does not 'look right' to me.
I put a lot of effort in making the macro syntax as natural as possible based on many comments from Boosters. Do you really find this code hard to follow? If so why?
int max = 0; bool BOOST_LOCAL_FUNCTION_PARAMS(int x, const bind max) { // (1) return x< a; } BOOST_LOCAL_FUNCTION_NAME(small) small(10);
just using phoenix and/or lambda :
int max = 0; auto small = _1 < max; // (2)
Or even better: int max = 0; auto small = [max](int x) { return x < max; } // (3) IMO (and others have second this point), (3) is better than (2) because at some point (3+ years from now?) everyone will be comfortable with C++11 lambda syntax (3) because it's part of the standard while there will still be people on your team that will have no idea what you meant in writing (2). By the same token, the syntax of (1) (statement syntax for the body) can be considered better than the one of (2) even if (1) is more verbose and than (2) (verbosity which might be a plus in the context to make the syntax more clear-- in fact (3) is more verbose than (2) but it is the new standard). All of that said, if the a syntax is more or less understandable is a subjective matter so I recognize that you and/or Hartmut feel differently on this topic.
local functions could be nice fi you have huge ones. One liners becomes nightmares and if you have a huge local function, make it a function.
IMO, we should leave these trade-offs to our library users: They can decide to write 1-liners with (2), longer functions still locally with (1), move out the function to non-local scope, or something else. Why wouldn't we entrust our library users to be able to make the best decision given that they will be ones directly facing the problem they are trying to solve? Why wouldn't we provide tools/libraries to allow them to chose in between these different options? Thanks for your comments, --Lorenzo
On 11/23/2011 7:06 PM, Lorenzo Caminiti wrote:
just using phoenix and/or lambda :
int max = 0; auto small = _1 < max; // (2)
Or even better:
int max = 0; auto small = [max](int x) { return x < max; } // (3)
IMO (and others have second this point), (3) is better than (2) because at some point (3+ years from now?) everyone will be comfortable with C++11 lambda syntax (3) because it's part of the standard while there will still be people on your team that will have no idea what you meant in writing (2). By the same token, the syntax of (1) (statement syntax for the body) can be considered better than the one of (2) even if (1) is more verbose and than (2) (verbosity which might be a plus in the context to make the syntax more clear-- in fact (3) is more verbose than (2) but it is the new standard). All of that said, if the a syntax is more or less understandable is a subjective matter so I recognize that you and/or Hartmut feel differently on this topic.
No it's not better. First: (3) is not polymorphic! (2) can be reused regardless of the type of _1. To make it clear: auto less = _1 < _2; The above can be reused in any expression as long as they have the less-than relation. E.g. less(i, 123), less(str, "hello), etc. It's these simple 1-2-3 liners where Phx/Lambda shine. You'd have to be absurdly dumb to get those expressions wrong! Second: (2) is more succinct. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Wed, Nov 23, 2011 at 6:54 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
On 11/23/2011 7:06 PM, Lorenzo Caminiti wrote:
just using phoenix and/or lambda :
int max = 0; auto small = _1 < max; // (2)
Or even better:
int max = 0; auto small = [max](int x) { return x < max; } // (3)
IMO (and others have second this point), (3) is better than (2) because at some point (3+ years from now?) everyone will be comfortable with C++11 lambda syntax (3) because it's part of the standard while there will still be people on your team that will have no idea what you meant in writing (2). By the same token, the syntax of (1) (statement syntax for the body) can be considered better than the one of (2) even if (1) is more verbose and than (2) (verbosity which might be a plus in the context to make the syntax more clear-- in fact (3) is more verbose than (2) but it is the new standard). All of that said, if the a syntax is more or less understandable is a subjective matter so I recognize that you and/or Hartmut feel differently on this topic.
No it's not better. First: (3) is not polymorphic! (2) can be reused regardless of the type of _1. To make it clear:
auto less = _1 < _2;
The above can be reused in any expression as long as they have the less-than relation. E.g. less(i, 123), less(str, "hello), etc. It's these simple 1-2-3 liners where Phx/Lambda shine. You'd have to be absurdly dumb to get those expressions wrong!
Second: (2) is more succinct.
For some of our users/problems polymorphism might not be relevant while using statement syntax for the body might. For those users/problems (3) might be worst than (2) because is does not use statement syntax in its body (worst error messages + less readable by others). We leave that decision up to our library users and we are all content. --Lorenzo
On 23/11/2011 13:04, Lorenzo Caminiti wrote:
For some of our users/problems polymorphism might not be relevant
If it is not relevant, you dont lose anything, polymorphism incldues monomorphism.
while using statement syntax for the body might. For those users/problems (3) might be worst than (2) because is does not use statement syntax in its body (worst error messages + less readable by others). We leave that decision up to our library users and we are all content.
The readability of error message is nothign more than a strawman argument. Lemme paraphrase Eric Niebler on the subject : "Template based library outputing walls of error are library with usability bug and these should be fixed". We have the tools for that (static assert, non-cascading dispatch on error etc), th eproblem is peopel just don't get this and bitch about the error instead of filling bugs for the rror to be spotted and corrected. It was a time peopel were bitchign about error from std::vector instanciated with a non-default constructible type, now everybody get it right.
On Thu, Nov 24, 2011 at 2:43 AM, Joel Falcou <joel.falcou@gmail.com> wrote:
On 23/11/2011 13:04, Lorenzo Caminiti wrote:
For some of our users/problems polymorphism might not be relevant
If it is not relevant, you dont lose anything, polymorphism incldues monomorphism.
Again, in this context with polymorphism you loose statement syntax for your function bodies.
while using statement syntax for the body might. For those users/problems (3) might be worst than (2) because is does not use statement syntax in its body (worst error messages + less readable by others). We leave that decision up to our library users and we are all content.
The readability of error message is nothign more than a strawman argument. Lemme paraphrase Eric Niebler on the subject : "Template based library outputing walls of error are library with usability bug and these should be fixed". We have the tools for that (static assert, non-cascading dispatch on error etc), th eproblem is peopel just don't get this and bitch about the error instead of filling bugs for the rror to be spotted and corrected.
It was a time peopel were bitchign about error from std::vector instanciated with a non-default constructible type, now everybody get it right.
Again, the argument (which many, many of our library users have made thus IMO we should not discard) is both the errors and the fact that the non-statement body syntax is not familiar to many (so not "just the errors"). HTH, --Lorenzo
On 24 November 2011 07:43, Joel Falcou <joel.falcou@gmail.com> wrote:
Lemme paraphrase Eric Niebler on the subject : "Template based library outputing walls of error are library with usability bug and these should be fixed". We have the tools for that (static assert, non-cascading dispatch on error etc), th eproblem is peopel just don't get this and bitch about the error instead of filling bugs for the rror to be spotted and corrected.
We can only use the things we have, not what we could potentially have. And what we have is horrendous error messages. And it takes more than filing bugs to fix that.
On 24/11/2011 10:40, Daniel James wrote:
On 24 November 2011 07:43, Joel Falcou<joel.falcou@gmail.com> wrote:
Lemme paraphrase Eric Niebler on the subject : "Template based library outputing walls of error are library with usability bug and these
should be
fixed". We have the tools for that (static assert, non-cascading dispatch on error etc), th eproblem is peopel just don't get this and bitch about the error instead of filling bugs for the rror to be spotted and corrected.
We can only use the things we have, not what we could potentially have. And what we have is horrendous error messages. And it takes more than filing bugs to fix that.
I am just asking users to actually be vocal about such error walls so the situation comes up to our level of consciousness. These are bugs like other, except it is diffcult to preemptively find them due to the fact some slight details of suer defined types may induce such phenomena. Then, th etool for fixing them are there, static-assert and concept check are working rather nicely once you actually use them.
On Thu, Nov 24, 2011 at 9:30 PM, Joel Falcou <joel.falcou@gmail.com> wrote:
On 24/11/2011 10:40, Daniel James wrote: [snip]
We can only use the things we have, not what we could potentially have. And what we have is horrendous error messages. And it takes more than filing bugs to fix that.
I am just asking users to actually be vocal about such error walls so the situation comes up to our level of consciousness. These are bugs like other, except it is diffcult to preemptively find them due to the fact some slight details of suer defined types may induce such phenomena.
Then, th etool for fixing them are there, static-assert and concept check are working rather nicely once you actually use them.
+1 Although I've always thought that bad error messages were because current compilers suck at making intelligible error messages. Cheers -- Dean Michael Berris http://goo.gl/CKCJX
On 11/24/2011 6:37 PM, Dean Michael Berris wrote:
On Thu, Nov 24, 2011 at 9:30 PM, Joel Falcou <joel.falcou@gmail.com> wrote:
On 24/11/2011 10:40, Daniel James wrote: [snip]
We can only use the things we have, not what we could potentially have. And what we have is horrendous error messages. And it takes more than filing bugs to fix that.
I am just asking users to actually be vocal about such error walls so the situation comes up to our level of consciousness. These are bugs like other, except it is diffcult to preemptively find them due to the fact some slight details of suer defined types may induce such phenomena.
Then, th etool for fixing them are there, static-assert and concept check are working rather nicely once you actually use them.
+1
Although I've always thought that bad error messages were because current compilers suck at making intelligible error messages.
++i It saddens me to see TMP-phobia creeping into Boost, of all places! :( Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 24 November 2011 10:47, Joel de Guzman <joel@boost-consulting.com> wrote:
On 11/24/2011 6:37 PM, Dean Michael Berris wrote:
On Thu, Nov 24, 2011 at 9:30 PM, Joel Falcou <joel.falcou@gmail.com> wrote:
Then, th etool for fixing them are there, static-assert and concept check are working rather nicely once you actually use them.
Do that then. Fix these problems and you'll prove me wrong. Wouldn't that be nice?
+1
Although I've always thought that bad error messages were because current compilers suck at making intelligible error messages.
Not an easy problem to fix. Most people are more concerned with getting shiny new features than usability.
++i
It saddens me to see TMP-phobia creeping into Boost, of all places! :(
To use something effectively requires understanding the disadvantages. You can't wish them away with a silly label. If people find something difficult to use, then it is difficult to use.
On Thu, Nov 24, 2011 at 10:46 PM, Daniel James <dnljms@gmail.com> wrote:
On 24 November 2011 10:47, Joel de Guzman <joel@boost-consulting.com> wrote:
On 11/24/2011 6:37 PM, Dean Michael Berris wrote:
On Thu, Nov 24, 2011 at 9:30 PM, Joel Falcou <joel.falcou@gmail.com> wrote:
Then, th etool for fixing them are there, static-assert and concept check are working rather nicely once you actually use them.
Do that then. Fix these problems and you'll prove me wrong. Wouldn't that be nice?
Right/Wrong is so overrated. ;)
+1
Although I've always thought that bad error messages were because current compilers suck at making intelligible error messages.
Not an easy problem to fix.
I agree. Never said it was easy though.
Most people are more concerned with getting shiny new features than usability.
Which is unfortunate because it can't just be fixed by the library writers because the compiler is the one that generates the error messages, not the library.
++i
It saddens me to see TMP-phobia creeping into Boost, of all places! :(
To use something effectively requires understanding the disadvantages.
I always thought it was that to use something effectively requires understanding the problem and whether that thing you have can be part of a solution. Disadvantages only come into play when you're covering the downside. If the tool is the right tool for the job and you know how to use it, would understanding the disadvantages stop you from using the tool?
You can't wish them away with a silly label. If people find something difficult to use, then it is difficult to use.
... for those people. That doesn't necessarily mean it matters whether they find it difficult to use if it's effective when it works and used correctly. Does that remind you of a programming language we all use? Cheers -- Dean Michael Berris http://goo.gl/CKCJX
On 24 November 2011 11:58, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Thu, Nov 24, 2011 at 10:46 PM, Daniel James <dnljms@gmail.com> wrote:
On 24 November 2011 10:47, Joel de Guzman <joel@boost-consulting.com> wrote:
It saddens me to see TMP-phobia creeping into Boost, of all places! :(
To use something effectively requires understanding the disadvantages.
I always thought it was that to use something effectively requires understanding the problem and whether that thing you have can be part of a solution. Disadvantages only come into play when you're covering the downside. If the tool is the right tool for the job and you know how to use it, would understanding the disadvantages stop you from using the tool?
No, I'm not saying "don't use it". I'm saying that understanding and acknowledging the disadvantages lets you make better use of the tool. When someone says that it's difficult to use, the response seems to be to argue with them and tell them they're wrong. That's not solving the problem, it's making it worse.
You can't wish them away with a silly label. If people find something difficult to use, then it is difficult to use.
... for those people. That doesn't necessarily mean it matters whether they find it difficult to use if it's effective when it works and used correctly. Does that remind you of a programming language we all use?
Much of boost deals with reducing C++'s usability problems. For one example, look at how shared_ptr deals with deleting objects that were allocated in a shared library.
On Fri, Nov 25, 2011 at 6:08 AM, Daniel James <dnljms@gmail.com> wrote:
On 24 November 2011 11:58, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Thu, Nov 24, 2011 at 10:46 PM, Daniel James <dnljms@gmail.com> wrote:
On 24 November 2011 10:47, Joel de Guzman <joel@boost-consulting.com> wrote:
It saddens me to see TMP-phobia creeping into Boost, of all places! :(
To use something effectively requires understanding the disadvantages.
I always thought it was that to use something effectively requires understanding the problem and whether that thing you have can be part of a solution. Disadvantages only come into play when you're covering the downside. If the tool is the right tool for the job and you know how to use it, would understanding the disadvantages stop you from using the tool?
No, I'm not saying "don't use it". I'm saying that understanding and acknowledging the disadvantages lets you make better use of the tool.
Why do the disadvantages make you use the tool better? Shouldn't the advantages do that instead?
When someone says that it's difficult to use, the response seems to be to argue with them and tell them they're wrong. That's not solving the problem, it's making it worse.
When someone says it's difficult to use, it doesn't say anything useful. Difficult is relative -- difficult compared to what? Because it's a very relative thing (like whether something is ugly or beautiful) discussing anything that pertains to 'difficulty'. What are the problems can be solved? Those that are demonstrably quantifiable. If the problem is there's 100KB of error messages generated by compiler A using library X, should it be a matter of the library being broken automatically or should it be that the compiler is broken? I'd wager if the compiler didn't barf 100KB of error messages for a seemingly "innocent" mistake done by the human in the equation, then maybe that human wouldn't be complaining regardless of whether library X was used or not. I just want to be clear here: there are two tools involved, one is the library and the other is the compiler. Fixing the correct broken tool should be the solution. Any discussion on fixing the wrong "not broken" tool is moot.
You can't wish them away with a silly label. If people find something difficult to use, then it is difficult to use.
... for those people. That doesn't necessarily mean it matters whether they find it difficult to use if it's effective when it works and used correctly. Does that remind you of a programming language we all use?
Much of boost deals with reducing C++'s usability problems. For one example, look at how shared_ptr deals with deleting objects that were allocated in a shared library.
No, much of Boost deals with improving C++'s usability _when the code compiles_. When the user's code doesn't compile then all bets are off, no library can manage what the compiler spits out in case there's an error in the code. Cheers -- Dean Michael Berris http://goo.gl/CKCJX
On 11/25/2011 10:28 AM, Dean Michael Berris wrote:
When someone says that it's difficult to use, the response seems to be
to argue with them and tell them they're wrong. That's not solving the problem, it's making it worse.
When someone says it's difficult to use, it doesn't say anything useful. Difficult is relative -- difficult compared to what? Because it's a very relative thing (like whether something is ugly or beautiful) discussing anything that pertains to 'difficulty'.
What are the problems can be solved? Those that are demonstrably quantifiable. If the problem is there's 100KB of error messages generated by compiler A using library X, should it be a matter of the library being broken automatically or should it be that the compiler is broken? I'd wager if the compiler didn't barf 100KB of error messages for a seemingly "innocent" mistake done by the human in the equation, then maybe that human wouldn't be complaining regardless of whether library X was used or not.
I just want to be clear here: there are two tools involved, one is the library and the other is the compiler. Fixing the correct broken tool should be the solution. Any discussion on fixing the wrong "not broken" tool is moot.
Or somewhere in between the compiler and user (i.e. UI). See my other post: Re: TMP error messages I'd really like to pin this down. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 24/11/2011 12:46, Daniel James wrote:
On 24 November 2011 10:47, Joel de Guzman<joel@boost-consulting.com> wrote:
On 11/24/2011 6:37 PM, Dean Michael Berris wrote:
On Thu, Nov 24, 2011 at 9:30 PM, Joel Falcou<joel.falcou@gmail.com> wrote:
Then, th etool for fixing them are there, static-assert and
concept check
are working rather nicely once you actually use them.
Do that then. Fix these problems and you'll prove me wrong. Wouldn't that be nice?
At which point did you stopped reading my email ? Before the point where I said that we're more willing to fix them as users report them. I repeat we cannot preemptively fix all of them as problem usually arise with improper designed user data type with respect to the constraint the TMP awaits for. So now, if reporting bug is too hard to do, then we can't help this much ... Do you bitch at regular library when, if calling a function takign a float with a char* you get "errors" ? This situation is the same. Error-walls are symptomatic of inadequacy between user input (here types) vs expectations. I am very sorry we cant Unit Tests against all possible user types.
On 24 November 2011 13:41, Joel Falcou <joel.falcou@gmail.com> wrote:
On 24/11/2011 12:46, Daniel James wrote:
Do that then. Fix these problems and you'll prove me wrong. Wouldn't that be nice?
At which point did you stopped reading my email ? Before the point where I said that we're more willing to fix them as users report them.
But you're not fixing them, you're just writing about fixing them. When someone did post an error message, this was the response: http://lists.boost.org/Archives/boost/2011/11/188198.php If fixing them requires waiting for something that isn't happening then they won't get fixed.
I repeat we cannot preemptively fix all of them as problem usually arise with improper designed user data type with respect to the constraint the TMP awaits for. So now, if reporting bug is too hard to do, then we can't help this much ...
Then you're stuck. So you have to work out a way forward. Go through the archives, search stack overflow, look at where people have gone wrong. Try compiling bad examples different compilers. Write your own test cases. Think about how it can be improved. Think about where they're going wrong and where they will go wrong. Try to understand why people are having problems. Read through those horrible errors, think about how to help the compiler give better errors etc. Alternatively, you could just decide that you don't want those people to use your library.
Do you bitch at regular library when, if calling a function takign a float with a char* you get "errors" ?
But I know how to decipher complicated error messages, you're asking the wrong person. And I try not to bitch, most of the time I try to be constructive.
Le 24/11/2011 20:09, Daniel James a écrit :
But you're not fixing them, you're just writing about fixing them. When someone did post an error message, this was the response:
http://lists.boost.org/Archives/boost/2011/11/188198.php
If fixing them requires waiting for something that isn't happening then they won't get fixed.
Pro tips : I am not joel de Guzman, neither have I any foot in Phoenix/spirit development. So dont put his word in my mouth. And with regard to this response, i dont see what he could have said more precisely. Assert at compile time are meant to give you this and int his very example, it fits the bill. The error points to a porper place with a proper informations. Using any modern dev tool filter error for you and most prehistoric one have at least a feature to do Search for in output. So unless you're writing code using vi on a 14x28 terminal, I dont see the problem with asking you to search for errors in the output.
Then you're stuck. So you have to work out a way forward. Go through the archives, search stack overflow, look at where people have gone wrong. Try compiling bad examples different compilers. Write your own test cases. Think about how it can be improved. Think about where they're going wrong and where they will go wrong. Try to understand why people are having problems. Read through those horrible errors, think about how to help the compiler give better errors etc.
No we're not stuck. Sorry to not have time and ressources to crawl the Internet all day long for this. Speakign on my own yard - Proto - a quick glance at SO show me this : http://stackoverflow.com/questions/tagged/boost-proto Ho and behold, no one cringe about error but are struggling wiht how to best use a given set of feature or to add some behavior in some way. Looking for spirit show more questions about feature than rantign about error messages ... In both cases, Eric, me or any Spirit people are actually answering these people. So now, which hell hole of the internet am I suppsoed to check ? It's nto liek we have an issue tracker at boost that people can use.
Alternatively, you could just decide that you don't want those people to use your library.
Alternatively, it could be nice if you could drop all this band wagon of strawmen ...
But I know how to decipher complicated error messages, you're asking the wrong person. And I try not to bitch, most of the time I try to be constructive.
You clearly fail there.
participants (7)
-
Daniel James -
Dean Michael Berris -
Hartmut Kaiser -
Joel de Guzman -
Joel Falcou -
Lorenzo Caminiti -
Steven Watanabe