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.