Deprecate BOOST_STATIC_ASSERT?
Yesterday someone on the user's list posted a message (http://article.gmane.org/gmane.comp.lib.boost.user/36884) about a "compilation error in the boost code:" s-test.h:49: instantiated from here /usr/include/boost/archive/detail/oserializer.hpp:567: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>' make: *** [stest] Error 1 and proceeded to try to analyze the BOOST_STATIC_ASSERT implementation to see what was wrong with it. Granted, most people figure out what a static assertion is supposed to be, but still, the error message gave no clue about what might have gone wrong... no clue to the user, and no clue to anyone reading his posting, unless they were going to look up the line in the source file... oops, I take it back. My copy of oserializer.hpp doesn't even have a line 567, and the posting doesn't indicate which version the user has. For several releases now we've had a suite of static assertion tools that give far superior error messages to what BOOST_STATIC_ASSERT can provide (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html). I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note in its documentation directing people at the BOOST_MPL_ASSERT macros. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Jun 20, 2008 at 12:41 PM, David Abrahams <dave@boostpro.com> wrote:
Hi David, [snip - bad user experience with BOOST_STATIC_ASSERT]
For several releases now we've had a suite of static assertion tools that give far superior error messages to what BOOST_STATIC_ASSERT can provide (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html). I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note in its documentation directing people at the BOOST_MPL_ASSERT macros.
Thoughts?
Couldn't BOOST_STATIC_ASSERT be implemented as: #define BOOST_STATIC_ASSERT(x) BOOST_MPL_ASSERT(x) ? I like how easy it is to use BOOST_STATIC_ASSERT: #include <boost/static_assert.hpp> BOOST_STATIC_ASSERT(( /*whatever*/ )); It is more straightforward than BOOST_MPL_ASSERT.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
-- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
On Fri, Jun 20, 2008 at 12:41 PM, David Abrahams <dave@boostpro.com> wrote:
Hi David,
[snip - bad user experience with BOOST_STATIC_ASSERT]
For several releases now we've had a suite of static assertion tools that give far superior error messages to what BOOST_STATIC_ASSERT can provide (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html). I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note in its documentation directing people at the BOOST_MPL_ASSERT macros.
Thoughts?
Couldn't BOOST_STATIC_ASSERT be implemented as:
#define BOOST_STATIC_ASSERT(x) BOOST_MPL_ASSERT(x)
?
No, it would have to be something like: BOOST_MPL_ASSERT(mpl::bool_<(x)>)
I like how easy it is to use BOOST_STATIC_ASSERT:
#include <boost/static_assert.hpp>
BOOST_STATIC_ASSERT(( /*whatever*/ ));
It is more straightforward than BOOST_MPL_ASSERT.
Yes, there is no doubt that it is more straightforward for the person writing the assertion. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Yesterday someone on the user's list posted a message (http://article.gmane.org/gmane.comp.lib.boost.user/36884) about a "compilation error in the boost code:"
s-test.h:49: instantiated from here /usr/include/boost/archive/detail/oserializer.hpp:567: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>' make: *** [stest] Error 1
and proceeded to try to analyze the BOOST_STATIC_ASSERT implementation to see what was wrong with it. Granted, most people figure out what a static assertion is supposed to be, but still, the error message gave no clue about what might have gone wrong... no clue to the user, and no clue to anyone reading his posting, unless they were going to look up the line in the source file... oops, I take it back. My copy of oserializer.hpp doesn't even have a line 567, and the posting doesn't indicate which version the user has.
For several releases now we've had a suite of static assertion tools that give far superior error messages to what BOOST_STATIC_ASSERT can provide (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html). I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note in its documentation directing people at the BOOST_MPL_ASSERT macros.
Thoughts?
If BOOST_MPL_ASSERT does a better job, why not just change BOOST_STATIC_ASSERT to be implemented in terms of BOOST_MPL_ASSERT? Also, C++0x static_assert is becoming available in more compilers; should all of the Boost compile-time asserts use C++0x static_assert if available? --Beman
Beman Dawes wrote:
If BOOST_MPL_ASSERT does a better job, why not just change BOOST_STATIC_ASSERT to be implemented in terms of BOOST_MPL_ASSERT?
Only because 1. There's more than one MPL assertion macro; one should choose the right one in order to get the best results. 2. you need to do a little bit more than write a simple integral constant expression to get really useful error output from the MPL assertions
Also, C++0x static_assert is becoming available in more compilers; should all of the Boost compile-time asserts use C++0x static_assert if available?
Without knowing anything about how good the error messages are that one gets from static_assert, I'd say "probably." -- Dave Abrahams BoostPro Computing http://www.boostpro.com
AMDG David Abrahams wrote:
Without knowing anything about how good the error messages are that one gets from static_assert, I'd say "probably.
I rather doubt that implementing BOOST_STATIC_ASSERT in terms of static_assert is going to create significantly better error messages, since it will still be a generic error message. In Christ, Steven Watanabe
Fully agreed and I didn't mean to suggest otherwise. There will be a small improvement in that distracting and irrelevant details like sizeof won't appear. Sent from my iPhone On Jun 23, 2008, at 6:48 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
David Abrahams wrote:
Without knowing anything about how good the error messages are that one gets from static_assert, I'd say "probably.
I rather doubt that implementing BOOST_STATIC_ASSERT in terms of static_assert is going to create significantly better error messages, since it will still be a generic error message.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG David Abrahams wrote:
Fully agreed and I didn't mean to suggest otherwise. There will be a small improvement in that distracting and irrelevant details like sizeof won't appear.
I'm inclined to worry that even though static_assert produces a prettier message than BOOST_MPL_ASSERT, it will actually be less useful because the error message doesn't contain information about the types involved. At least, I don't see an easier way than to put the static_assert in an auxiliary template. In Christ, Steven Watanabe
David Abrahams wrote:
Beman Dawes wrote: ...
Also, C++0x static_assert is becoming available in more compilers; should all of the Boost compile-time asserts use C++0x static_assert if available?
Without knowing anything about how good the error messages are that one gets from static_assert, I'd say "probably."
Sample program: int main() { static_assert(1+1==3, "Everyone knows 1+1 == 4"); return 0; } Output from a beta compiler: temp3.cpp: Error E2538 temp3.cpp 3: Static assert failed: 'Everyone knows 1+1 == 4' in function main() *** 1 errors in Compile *** That's what I'd expect from most compilers; the file name and line number of the failure, and an echo of the second argument to static_assert. So it comes down to writing informative error messages. I like the ones that say both what is wrong and what to do to fix it, but that's often hard to do in limited space. --Beman
David Abrahams wrote:
I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea>
or at *least* put a prominent note
in its documentation directing people at the BOOST_MPL_ASSERT macros.
I think there is a deeper problem here. There are a number of facilities which are used in boost whose documentation and purpose are hard to find. In particular I refer to things like: assert vs BOOST_ASSERT BOOST_STATIC_ASSERT vs BOOST_MPL_ASSERT a few "exception", throw_exception, etc. I recently had to find something to do with some aspect of exception and I had to search around and finally decifer the source code. There is some documentation in boost "rationale" about things like "throw" specifications. I think it would be very valuable to update a few of these documents. (another one that is really out of date is "how to write documentation for boost". I suspect that lots people look at other boost code for answers to questions. I think improving the documents which address these questions would go along way toward changing the practice. It would never occur to me to look into the MPL library for a replacement for BOOST_STATIC_ASSERT. And since MPL is and "advanced" library - most users aren't going to become familiar with it until they already spend a significant amount of time with boost. Oh - Of course I see now what I really want to use is the Boost concept library. But its not clear to me that this is not in a state of flux. In this specific case, I changed BOOST_STATIC_ASSERT to BOOST_STATIC_WARNING - which suffers from the same problem but may be better for some users. Maybe you might re-implement BOOST_STATIC_ASSERT in terms of BOOST_MPL_ASSERT - I don't know if that would help. Is there a BOOST_MPL_WARNING? Robert Ramey
Robert Ramey wrote:
David Abrahams wrote:
I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea>
or at *least* put a prominent note
in its documentation directing people at the BOOST_MPL_ASSERT macros.
I think there is a deeper problem here.
There are a number of facilities which are used in boost whose documentation and purpose are hard to find.
It's true, that's a problem. It's a different, though loosely related problem that is much larger in scope. At the risk of distracting attention from the small problem I raised, do you have any ideas for addressing it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Yesterday someone on the user's list posted a message (http://article.gmane.org/gmane.comp.lib.boost.user/36884) about a "compilation error in the boost code:"
s-test.h:49: instantiated from here /usr/include/boost/archive/detail/oserializer.hpp:567: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>' make: *** [stest] Error 1
and proceeded to try to analyze the BOOST_STATIC_ASSERT implementation to see what was wrong with it. Granted, most people figure out what a static assertion is supposed to be, but still, the error message gave no clue about what might have gone wrong... no clue to the user, and no clue to anyone reading his posting, unless they were going to look up the line in the source file... oops, I take it back. My copy of oserializer.hpp doesn't even have a line 567, and the posting doesn't indicate which version the user has.
For several releases now we've had a suite of static assertion tools that give far superior error messages to what BOOST_STATIC_ASSERT can provide (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html). I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note in its documentation directing people at the BOOST_MPL_ASSERT macros.
Thoughts?
As a user and a library writer I would ask to keep BOOST_STATIC_ASSERT as it is without deprecation. I'm using this macro on a regular basis and found no problems with it. I usually put a comment near the macro that explains what the check does and I'm very sure the comment will be far more informative than any compiler-generated error message (unless we are speaking of static_assert in C++0x). I wouldn't like to move to BOOST_MPL_ASSERT since (a) it would require to change my code (b) it would complicate condition expressions with compile-time constants and (c) it would introduce dependency on MPL where there was no such dependency. However, I think pointers to MPL docs near BOOST_STATIC_ASSERT description is a good idea.
Andrey Semashev wrote:
As a user and a library writer I would ask to keep BOOST_STATIC_ASSERT as it is without deprecation. I'm using this macro on a regular basis and found no problems with it. I usually put a comment near the macro that explains what the check does and I'm very sure the comment will be far more informative than any compiler-generated error message (unless we are speaking of static_assert in C++0x).
Oh, I agree. Probably even if we _are_ speaking of static_assert in C++0x. The problem of course is that (generalizing wildly here): 1. users don't look at the code 2. users can't even locate the line where the error occurred in a long instantiation backtrace 3. the part of the backtrace they paste into their problem reports doesn't contain the information you need to know what went wrong. The point is that BOOST_MPL_ASSERT does a better job of highlighting the actual problem.
I wouldn't like to move to BOOST_MPL_ASSERT since (a) it would require to change my code (b) it would complicate condition expressions with compile-time constants
How do you manage to use BOOST_STATIC_ASSERT without compile-time constants?
and (c) it would introduce dependency on MPL where there was no such dependency.
That can be dealt with, if necessary, by factoring out that part of the library. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Andrey Semashev wrote:
As a user and a library writer I would ask to keep BOOST_STATIC_ASSERT as it is without deprecation. I'm using this macro on a regular basis and found no problems with it. I usually put a comment near the macro that explains what the check does and I'm very sure the comment will be far more informative than any compiler-generated error message (unless we are speaking of static_assert in C++0x).
Oh, I agree. Probably even if we _are_ speaking of static_assert in C++0x. The problem of course is that (generalizing wildly here):
1. users don't look at the code
True, at least they don't want to.
2. users can't even locate the line where the error occurred in a long instantiation backtrace
BOOST_MPL_ASSERT does no better here. It allows to put some hints on the problem source in the error message but nothing more. But even that makes little good since it can be difficult to find those hints in the backtrace. IMHO, most of the time users will eventually want to see the comment near the check anyway (and with experience I find it easier than decyphering rant of the compiler).
3. the part of the backtrace they paste into their problem reports doesn't contain the information you need to know what went wrong.
The point is that BOOST_MPL_ASSERT does a better job of highlighting the actual problem.
I think this point is oriented towards Boost maintainers. We should not forget that BOOST_STATIC_ASSERT is a part of public interface and users use it too. By deprecating it we effectively forbid to use it. I think if a Boost (or non-Boost) library maintainer wants he can use MPL macros to improve compiler-generated messages, he just needs to know that they exist. No need to bother users.
I wouldn't like to move to BOOST_MPL_ASSERT since (a) it would require to change my code (b) it would complicate condition expressions with compile-time constants
How do you manage to use BOOST_STATIC_ASSERT without compile-time constants?
With types and type traits. That makes BOOST_STATIC_ASSERT usage similar to BOOST_MPL_ASSERT, though.
and (c) it would introduce dependency on MPL where there was no such dependency.
That can be dealt with, if necessary, by factoring out that part of the library.
Maybe that should not be a part of MPL? After all, compiler diagnostics is out of scope of the library. I think, Boost.StaticAssert library would be a better place for such facilities.
Andrey Semashev wrote:
David Abrahams wrote:
Andrey Semashev wrote:
As a user and a library writer I would ask to keep BOOST_STATIC_ASSERT as it is without deprecation. I'm using this macro on a regular basis and found no problems with it. I usually put a comment near the macro that explains what the check does and I'm very sure the comment will be far more informative than any compiler-generated error message (unless we are speaking of static_assert in C++0x).
Oh, I agree. Probably even if we _are_ speaking of static_assert in C++0x. The problem of course is that (generalizing wildly here):
1. users don't look at the code
True, at least they don't want to.
2. users can't even locate the line where the error occurred in a long instantiation backtrace
BOOST_MPL_ASSERT does no better here.
It makes one part of the message stand out better than the others. You don't think ****************** error-message:: ********************* is more likely to get noticed and pasted into a problem report?
It allows to put some hints on the problem source in the error message but nothing more. But even that makes little good since it can be difficult to find those hints in the backtrace.
Seriously? You don't find those asterixes make things stand out sufficiently?
IMHO, most of the time users will eventually want to see the comment near the check anyway (and with experience I find it easier than decyphering rant of the compiler).
You said yourself that users don't want to look at the code. The comment is in the code.
3. the part of the backtrace they paste into their problem reports doesn't contain the information you need to know what went wrong.
The point is that BOOST_MPL_ASSERT does a better job of highlighting the actual problem.
I think this point is oriented towards Boost maintainers. We should not forget that BOOST_STATIC_ASSERT is a part of public interface and users use it too. By deprecating it we effectively forbid to use it.
Not exactly, although your point is taken. I am not arguing that it should be forbidden.
I think if a Boost (or non-Boost) library maintainer wants he can use MPL macros to improve compiler-generated messages, he just needs to know that they exist. No need to bother users.
Which users? How is that group different from the group of Boost (or non-Boost) library maintainers?
I wouldn't like to move to BOOST_MPL_ASSERT since (a) it would require to change my code (b) it would complicate condition expressions with compile-time constants
How do you manage to use BOOST_STATIC_ASSERT without compile-time constants?
With types and type traits.
Err, BOOST_STATIC_ASSERT((expression)) requires that expression is a compile-time constant, whether it involves types and traits or not. Perhaps you meant something else, such as...
That makes BOOST_STATIC_ASSERT usage similar to BOOST_MPL_ASSERT, though.
"...complicate condition expressions with types and type traits." Well, if you're using types and type traits anyway, the tendency of BOOST_MPL_ASSERT is to make your condition expressions much *simpler* than they would be with BOOST_STATIC_ASSERT. And if you're writing an expression that is simpler *without* types and type traits, BOOST_MPL_ASSERT_RELATION is often a better bet anyway.
and (c) it would introduce dependency on MPL where there was no such dependency.
That can be dealt with, if necessary, by factoring out that part of the library.
Maybe that should not be a part of MPL?
I don't know whether it should or shouldn't, but separating it from MPL was what "factoring out that part of the library" was meant to suggest.
After all, compiler diagnostics is out of scope of the library. I think, Boost.StaticAssert library would be a better place for such facilities.
That approach would be okay with me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Andrey Semashev wrote:
David Abrahams wrote:
Andrey Semashev wrote:
1. users don't look at the code True, at least they don't want to.
2. users can't even locate the line where the error occurred in a long instantiation backtrace BOOST_MPL_ASSERT does no better here.
It makes one part of the message stand out better than the others. You don't think ****************** error-message:: ********************* is more likely to get noticed and pasted into a problem report?
It allows to put some hints on the problem source in the error message but nothing more. But even that makes little good since it can be difficult to find those hints in the backtrace.
Seriously? You don't find those asterixes make things stand out sufficiently?
This is a sample error report from BOOST_STATIC_ASSERT: ./assert1.cpp: In instantiation of ‘A<-0x00000000000000005>’: ./assert1.cpp:12: instantiated from here ./assert1.cpp:6: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’ And this is what BOOST_MPL_ASSERT_RELATION produces: ./assert2.cpp: In instantiation of ‘A<-0x00000000000000005>’: ./assert2.cpp:12: instantiated from here ./assert2.cpp:6: error: no matching function for call to ‘assertion_failed(mpl_::failed************ mpl_::assert_relation<greater, -0x00000000000000005l, 0l>::************)’ Honestly, I don't see much difference except that, as it was noted, there are hints to the problem source in the latter output. Upper-case STATIC_ASSERTION_FAILURE do highlight error just as well as those asterixes.
IMHO, most of the time users will eventually want to see the comment near the check anyway (and with experience I find it easier than decyphering rant of the compiler).
You said yourself that users don't want to look at the code. The comment is in the code.
That's right. What I meant is that they will eventually have to look in the code in either case, if they want to resolve the problem, that is.
I think if a Boost (or non-Boost) library maintainer wants he can use MPL macros to improve compiler-generated messages, he just needs to know that they exist. No need to bother users.
Which users?
The ones that use Boost libraries, not the ones that write them.
How is that group different from the group of Boost (or non-Boost) library maintainers?
It's not. What I'm saying is that if the problem that you describe (error reports that are not consistent with the code) is actual for a developer, he may use MPL macros to improve error messages. For me, as a Boost user, such problem does not exist because, obviously, I always have actual copy of my code when I get static assertions.
How do you manage to use BOOST_STATIC_ASSERT without compile-time constants? With types and type traits.
Err, BOOST_STATIC_ASSERT((expression)) requires that expression is a compile-time constant, whether it involves types and traits or not. Perhaps you meant something else, such as...
That makes BOOST_STATIC_ASSERT usage similar to BOOST_MPL_ASSERT, though.
"...complicate condition expressions with types and type traits."
Yes, a little: BOOST_STATIC_ASSERT((is_same< T, void >::value)); BOOST_MPL_ASSERT((is_same< T, void >)); I didn't know about BOOST_MPL_ASSERT before this topic and maybe I'll switch to it in such cases.
Well, if you're using types and type traits anyway, the tendency of BOOST_MPL_ASSERT is to make your condition expressions much *simpler* than they would be with BOOST_STATIC_ASSERT. And if you're writing an expression that is simpler *without* types and type traits, BOOST_MPL_ASSERT_RELATION is often a better bet anyway.
BOOST_MPL_ASSERT_RELATION is not generic enough for this, for example: BOOST_STATIC_ASSERT(x > 0 && x < 10); Besides, I don't like those commas between the relation and the arguments. It's a matter of taste, though.
AMDG Andrey Semashev wrote:
This is a sample error report from BOOST_STATIC_ASSERT:
./assert1.cpp: In instantiation of ‘A<-0x00000000000000005>’: ./assert1.cpp:12: instantiated from here ./assert1.cpp:6: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’
And this is what BOOST_MPL_ASSERT_RELATION produces:
./assert2.cpp: In instantiation of ‘A<-0x00000000000000005>’: ./assert2.cpp:12: instantiated from here ./assert2.cpp:6: error: no matching function for call to ‘assertion_failed(mpl_::failed************ mpl_::assert_relation<greater, -0x00000000000000005l, 0l>::************)’
Honestly, I don't see much difference except that, as it was noted, there are hints to the problem source in the latter output. Upper-case STATIC_ASSERTION_FAILURE do highlight error just as well as those asterixes.
If -0x00000000000000005l and 0l are the result of template metaprogramming rather than hard coded, the BOOST_STATIC_ASSERT message is /much/ less helpful, IMO. In Christ, Steven Watanabe
2008/6/23 David Abrahams <dave@boostpro.com>:
Andrey Semashev wrote:
David Abrahams wrote:
Andrey Semashev wrote:
...snip... Probably even if we _are_ speaking of static_assert in C++0x. The problem of course is that (generalizing wildly here):
1. users don't look at the code
True, at least they don't want to.
2. users can't even locate the line where the error occurred in a long instantiation backtrace
BOOST_MPL_ASSERT does no better here.
It makes one part of the message stand out better than the others. You don't think ****************** error-message:: ********************* is more likely to get noticed and pasted into a problem report?
I agree, plus BOOST_MPL_ASSERT_MSG() does an even better job of being obvious what's gone wrong: on my computer, MSVC it adds a *full* screen of errors, with the supplied error message (such as THE_NUMBER_SUPPLIED_WAS_OUT_OF_RANGE) stuck right in the middle of it, dumped in between loads of asterisks. Because the surrounding errors are pretty consistent (AFAICT) it makes them recognisable and easier to spot. It's a pity the mpl macros are so hard to find though. It'd be nice if they were documented directly in the static assert docs. -- Darren
Darren Garvey wrote:
2008/6/23 David Abrahams <dave@boostpro.com>:
It's a pity the mpl macros are so hard to find though. It'd be nice if they were documented directly in the static assert docs.
This is the key issue. For lots of people, the introduction to generic programming is through STATIC_ASSERT. This one facility is very useful and easy to use and understand. Any C++ programmer - even a newbie, can grasp the utility of this facility within minutes. MPL, though very powerful and useful, takes a significant amount of investment of effort to understand. Actually, I wouldn't expect that anyone in need of such a facility such as STATIC_ASSERT would even look there unless he happened to be already familiar with it. A good solution would be to factor out the MPL ASSERTS code and documentation into a separate library (boost/utility/static_assert?). I don't know if the MPL_ASSERTS work with compile time constants or just with types. If its the latter, then BOOST_STATIC_ASSERT would be in that same page. Since this would mostly be moving around a bunch of stuff that is already done, I would hope that its not a huge amount of work. Of course that would be my perception as I wouldn't be the one doing it. Oh, and while we're at it, may we can include BOOST_STATIC_WARNING in here as well? Robert Ramey
A good solution would be to factor out the MPL ASSERTS code and documentation into a separate library (boost/utility/static_assert?). I don't know if the MPL_ASSERTS work with compile time constants or just with types. If its the latter, then BOOST_STATIC_ASSERT would be in that same page. Since this would mostly be moving around a bunch of stuff that is already done, I would hope that its not a huge amount of work. Of course that would be my perception as I wouldn't be the one doing it. Oh, and while we're at it, may we can include BOOST_STATIC_WARNING in here as well?
That would be my preferance as well. Any takers? John.
John Maddock wrote:
A good solution would be to factor out the MPL ASSERTS code and documentation into a separate library (boost/utility/static_assert?). I don't know if the MPL_ASSERTS work with compile time constants or just with types. If its the latter, then BOOST_STATIC_ASSERT would be in that same page. Since this would mostly be moving around a bunch of stuff that is already done, I would hope that its not a huge amount of work. Of course that would be my perception as I wouldn't be the one doing it. Oh, and while we're at it, may we can include BOOST_STATIC_WARNING in here as well?
That would be my preferance as well.
Any takers?
Seems to me that if we were to go that way, *and* if people are generally agreed that the existing facilities use too many MPL headers (I am not yet convinced of that, BTW) Aleksey would at least need to be involved. AFAIK he's the only one who really understands the structure of MPL. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
For several releases now we've had a suite of static assertion tools that give far superior error messages to what BOOST_STATIC_ASSERT can provide (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html). I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note in its documentation directing people at the BOOST_MPL_ASSERT macros.
Thoughts?
One of the best things of BOOST_STATIC_ASSERT is that it's very lightweight and has just basic depedencies: #include <boost/config.hpp> #include <boost/detail/workaround.hpp> Looking mpl/assert.hpp: #include <boost/mpl/not.hpp> #include <boost/mpl/aux_/value_wknd.hpp> #include <boost/mpl/aux_/nested_type_wknd.hpp> #include <boost/mpl/aux_/yes_no.hpp> #include <boost/mpl/aux_/na.hpp> #include <boost/mpl/aux_/adl_barrier.hpp> #include <boost/mpl/aux_/config/nttp.hpp> #include <boost/mpl/aux_/config/dtp.hpp> #include <boost/mpl/aux_/config/gcc.hpp> #include <boost/mpl/aux_/config/msvc.hpp> #include <boost/mpl/aux_/config/static_constant.hpp> #include <boost/mpl/aux_/config/pp_counter.hpp> #include <boost/mpl/aux_/config/workaround.hpp> #include <boost/preprocessor/cat.hpp> #include <boost/config.hpp> // make sure 'size_t' is placed into 'std' #include <cstddef> This sounds a bit heavy. Can't we improve BOOST_STATIC_ASSERT a bit (or make mpl/assert.hpp a bit more lightweight)? For newer compilers BOOST_STATIC_ASSERT will be just a macro defining standard static assert. Regards, Ion
David Abrahams wrote:
Yesterday someone on the user's list posted a message (http://article.gmane.org/gmane.comp.lib.boost.user/36884) about a "compilation error in the boost code:"
s-test.h:49: instantiated from here /usr/include/boost/archive/detail/oserializer.hpp:567: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>' make: *** [stest] Error 1
and proceeded to try to analyze the BOOST_STATIC_ASSERT implementation to see what was wrong with it. Granted, most people figure out what a static assertion is supposed to be, but still, the error message gave no clue about what might have gone wrong... no clue to the user, and no clue to anyone reading his posting, unless they were going to look up the line in the source file... oops, I take it back. My copy of oserializer.hpp doesn't even have a line 567, and the posting doesn't indicate which version the user has.
For several releases now we've had a suite of static assertion tools that give far superior error messages to what BOOST_STATIC_ASSERT can provide (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html). I think <radical-idea>it's time to deprecate BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note in its documentation directing people at the BOOST_MPL_ASSERT macros.
Thoughts?
I'm in two minds over this: yes we should direct people to the best that we have. However, once compilers start supporting a native static_assert we can redirect BOOST_STATIC_ASSERT to that and get *much* better messages (of course the MPL macros may do the same thing). The other issue is with MPL's messages: sorry Dave, but the first time I saw an MPL assertion failure, my immediate reaction was "what the heck is that?" :-( I've certainly no objection to updating the docs to refer to the MPL asserts as well though. What do others think? John.
John Maddock wrote:
The other issue is with MPL's messages: sorry Dave, but the first time I saw an MPL assertion failure, my immediate reaction was "what the heck is that?" :-(
Don't you think everyone reacts the same way the first time they trigger a BOOST_STATIC_ASSERT? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
John Maddock wrote:
The other issue is with MPL's messages: sorry Dave, but the first time I saw an MPL assertion failure, my immediate reaction was "what the heck is that?" :-(
Don't you think everyone reacts the same way the first time they trigger a BOOST_STATIC_ASSERT?
I know I did, that's for sure. Anyway, Robert Ramey mentioned that Boost.MPL is not the obvious place for anyone to go browsing for a "better BOOST_STATIC_ASSERT". Heck, I didn't realize there was anything like that in there (though, in retrospect, I probably should have guessed). Possibly that part should be factored out, as you mentioned, and BOOST_STATIC_ASSERT implemented in terms of it, as a convenience macro? Of course, regardless, the whole shebang should probably use c++0x static_assert if available, but I've not yet seen the error messages produced by any of the compilers that already support it, so I'm in no position to judge really. /Brian
participants (11)
-
Andrey Semashev -
Beman Dawes -
Brian Ravnsgaard Riis -
Darren Garvey -
David Abrahams -
Felipe Magno de Almeida -
Ion Gaztañaga -
John Maddock -
John Maddock -
Robert Ramey -
Steven Watanabe