Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-23 13:07:45

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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at