From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-06-23 04:43:34
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk