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 sufficiently?
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 http://www.boostpro.com