Hello, I've just found out that the following program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT(false); return 0; } compiled with gcc 3.3 produces: sa.cpp:6: error: invalid application of `sizeof' to an incomplete type which is not as nice as sa.cpp:6: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' that gcc 2.95 generates and sa.cpp:6: `sizeof' applied to incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' That 3.2 generates. The behaviour of 3.4 is the same as for 3.3. So, there are some questions: 1. Should I bug gcc developers about this? 2. Anybody knows another way to force better diagnostic? 3. Is it possible to make regression tests for static_assert always include compiler messages, so that we know the diagnostic is OK? - Volodya
On Thu, Apr 15, 2004 at 10:46:23AM +0400, Vladimir Prus wrote:
Hello, I've just found out that the following program:
#include <boost/static_assert.hpp>
int main() { BOOST_STATIC_ASSERT(false); return 0; }
compiled with gcc 3.3 produces:
sa.cpp:6: error: invalid application of `sizeof' to an incomplete type
I'm kinda hijacking your message topic (apologies) but... More generally, I would really like a Boost library which lets me generate custom error messages portably. For example, with FC++, I spent a bit of time getting g++ to give "nice" diagnostics for certain kinds of errors -- for instance, compiling // uh oh... cout << lambda(X,X)[ X ](1,2) << endl; // lam2.cpp line 94 with g++-3.1.1 yields lambda.hpp: In function `boost::fcpp::lambda_impl::LambdaThingy< boost::fcpp::lambda_impl::exp::CONS< boost::fcpp::lambda_impl::exp::lambda_var<i>, boost::fcpp::lambda_impl::exp::CONS< boost::fcpp::lambda_impl::exp::lambda_var<i>, boost::fcpp::lambda_impl::exp::NIL> > > boost::fcpp::lambda_impl::lambda(const boost::fcpp::lambda_impl::exp::lambda_var<i>&, const boost::fcpp::lambda_impl::exp::lambda_var<i>&) [with int i = 4, int j = 4]': lam2.cpp:94: instantiated from here lambda.hpp:1137: no method `boost::fcpp::lambda_impl:: YouCannotPassTheSameLambdaVarTo_lambda_MoreThanOnce<true>::go' I am happy with the last two lines of the error message, which indicate both the source of the problem (lam2.cpp, line 94) and the issue (YouCannotPassTheSameLambdaVarTo_lambda_MoreThanOnce). However I got this working using completely ad-hoc techniques which maybe only work well for g++-3.1.1. What I would really love is if there were a boost library which enabled me to dispatch messages along the lines of BOOST_CUSTOM_ERROR( b, msg ) BOOST_CUSTOM_WARNING( b, msg ) where in both cases "b" is a compile-time boolean, "msg" is the name of a type, and the behavior is if the boolean is true force this compiler to generate a short diagnostic with typename "msg" featured prominently In the long run, there really needs to be language support for meta-programs to generate legible diagnostics, but in the meantime, I would love a stopgap solution along the lines above. I think it would "only" involve the work of finding the best "trick" for each compiler brand/version. Perhaps a little concerted effort would discover one trick which worked well across many compilers. Is there interest in this? -- -Brian McNamara (lorgon@cc.gatech.edu)
Brian McNamara wrote:
More generally, I would really like a Boost library which lets me generate custom error messages portably. ... lam2.cpp:94: instantiated from here lambda.hpp:1137: no method `boost::fcpp::lambda_impl:: YouCannotPassTheSameLambdaVarTo_lambda_MoreThanOnce<true>::go' ... What I would really love is if there were a boost library which enabled me to dispatch messages along the lines of
BOOST_CUSTOM_ERROR( b, msg ) BOOST_CUSTOM_WARNING( b, msg )
It probably should be a class which can be used like this: mpl::apply_if< ..., identity<int>, COMPILE_TIME_ERROR<Required_property_not_found> > ; Though I don't have a use case for this yet. If we want insantiation of COMPILE_TIME_ERROR to generate an error message, then error must be inside type declaration, since member functions are not instantiated. So the simplest version can be: template<class ErrorMessage> class COMPILE_TIME_ERROR { typedef typename ErrorMessage::oops type; }; class Life_is_hard {}; Which actually produces *very* nice output: sa.cpp: In instantiation of `COMPILE_TIME_ERROR<Life_is_hard>': /home/ghost/Work/boost/boost/mpl/apply_if.hpp:39: instantiated from `boost::mpl::apply_if<boost::mpl::int_<0>, boost::mpl::identity<int>, COMPILE_TIME_ERROR<Life_is_hard> >' sa.cpp:20: instantiated from here .... Which has "COMPILE_TIME_ERROR" in the very first line (other variants I've tried mention COMPILE_TIME_ERROR on the second/third/... line). But if some compiler generates good message only if error is inside function body we're out of luck. I attach my test if somebody is interested in trying on other compilers, and in case mailman will strip it, it's also at http://zigzag.cs.msu.su:7813/sa.cpp
where in both cases "b" is a compile-time boolean, "msg" is the name of a type, and the behavior is
if the boolean is true force this compiler to generate a short diagnostic with typename "msg" featured prominently
In the long run, there really needs to be language support for meta-programs to generate legible diagnostics, but in the meantime, I would love a stopgap solution along the lines above. I think it would "only" involve the work of finding the best "trick" for each compiler brand/version. Perhaps a little concerted effort would discover one trick which worked well across many compilers.
Possibly. Useing an non-existent method is likely to work.
Is there interest in this?
Sure. In particular, I'd like to see a number of static assertions added to BGL, to make error messages less confusing. - Volodya
"Brian McNamara" <lorgon@cc.gatech.edu> wrote
More generally, I would really like a Boost library which lets me generate custom error messages portably. [snip] What I would really love is if there were a boost library which enabled me to dispatch messages along the lines of
BOOST_CUSTOM_ERROR( b, msg ) BOOST_CUSTOM_WARNING( b, msg )
where in both cases "b" is a compile-time boolean, "msg" is the name of a type, and the behavior is
if the boolean is true force this compiler to generate a short diagnostic with typename "msg" featured prominently
Serialization library contains macro BOOST_STATIC_WARNING. It would be useful to lift this feature into utility or static assert or other visible place. /Pavel
Brian McNamara <lorgon@cc.gatech.edu> writes:
What I would really love is if there were a boost library which enabled me to dispatch messages along the lines of
BOOST_CUSTOM_ERROR( b, msg ) BOOST_CUSTOM_WARNING( b, msg )
You might look at boost/mpl/print.hpp -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On 4/15/04 3:20 AM, "Brian McNamara" <lorgon@cc.gatech.edu> wrote: [SNIP]
More generally, I would really like a Boost library which lets me generate custom error messages portably.
I don't think that's possible. I think error messages are a quality-of-implementation issue. There's nothing preventing a compiler from useless saying "diagnostic found" upon hitting the first error. [SNIP]
In the long run, there really needs to be language support for meta-programs to generate legible diagnostics, but in the meantime, I would love a stopgap solution along the lines above. I think it would "only" involve the work of finding the best "trick" for each compiler brand/version. Perhaps a little concerted effort would discover one trick which worked well across many compilers.
Is there interest in this?
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
On 4/15/04 3:20 AM, "Brian McNamara" <lorgon@cc.gatech.edu> wrote:
[SNIP]
More generally, I would really like a Boost library which lets me generate custom error messages portably.
I don't think that's possible. I think error messages are a quality-of-implementation issue. There's nothing preventing a compiler from useless saying "diagnostic found" upon hitting the first error.
There's "theoretical portability" and "in practice" portability. I think Brian was talking about the latter. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (6)
-
Brian McNamara -
Daryle Walker -
David Abrahams -
Giovanni Bajo -
Pavel Vozenilek -
Vladimir Prus