Re: [boost] Deprecate BOOST_STATIC_ASSERT?

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
>> 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.