From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-06-24 04:39:46
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
> Seriously? You don't find those asterixes make things stand out
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
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
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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk