While investigating this test failure.. http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/out... http://tinyurl.com/93yz9 Which is a compile-fail test, but compiles successfully with CW-8.3. I narrowed the problem down to this minimal test.. #include <boost/static_assert.hpp> template <std::size_t N> void foo_p() { BOOST_STATIC_ASSERT(N < 3); } int main() { foo_p<5>(); } ..Which compiles without problems. The static_assert code is simple enough so I'm somewhat at a loss here. Don't know how many other tests this affects but it seems kind of important to fix this. So any ideas on what sort of feature/bug this is hitting would be appreciated ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
While investigating this test failure..
http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/out... http://tinyurl.com/93yz9
Which is a compile-fail test, but compiles successfully with CW-8.3. I narrowed the problem down to this minimal test..
#include <boost/static_assert.hpp>
template <std::size_t N> void foo_p() { BOOST_STATIC_ASSERT(N < 3); }
int main() { foo_p<5>(); }
..Which compiles without problems. The static_assert code is simple enough so I'm somewhat at a loss here.
Are you running it with two-phase templates enabled? boost::checked_delete has a workaround for CW ignoring unreferenced dependent typedefs which might be of help here.
Peter Dimov wrote:
Rene Rivera wrote:
..Which compiles without problems. The static_assert code is simple enough so I'm somewhat at a loss here.
Are you running it with two-phase templates enabled?
We always are.
boost::checked_delete has a workaround for CW ignoring unreferenced dependent typedefs which might be of help here.
That's definitely the problem.. I'll look at the workaround and see if it can be used. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Peter Dimov wrote:
boost::checked_delete has a workaround for CW ignoring unreferenced dependent typedefs which might be of help here.
That's definitely the problem.. I'll look at the workaround and see if it can be used.
Well it helped for the function context. But of course "(void) sizeof(x);" breaks the rest of the non-function contexts that static_assert is used in. I've been trying all kinds of tricks to get the parser to instantiate the assert types. But CW takes the "does not require instantiation" of 1.14.7.1 to the extreme. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Rene Rivera wrote:
Peter Dimov wrote:
boost::checked_delete has a workaround for CW ignoring unreferenced dependent typedefs which might be of help here.
That's definitely the problem.. I'll look at the workaround and see if it can be used.
Well it helped for the function context. But of course "(void) sizeof(x);" breaks the rest of the non-function contexts that static_assert is used in.
I've been trying all kinds of tricks to get the parser to instantiate the assert types. But CW takes the "does not require instantiation" of 1.14.7.1 to the extreme.
That should be 14.7.1 :-) I've added a test to static_assert to see if other compilers have this problem. Howard's suggestions didn't help either. For example this.. doesn't work with CodeWarrior 8.x. And it case it was missed, this is not a problem with the 9.x version. ==== #include <msl_utility> template <int N> int foo() { typedef Metrowerks::int2type<sizeof( Metrowerks::compile_assert< N < 2 > my_assertion; return N; } int main() { return foo<9>(); } ==== This failure only worries me because it's likely hiding either a bunch of other failures, or successes. So if anyone has some idea on how to make a macro generate different code based on function or non-function context I would _love_ to know. PS.I already tried the *FUNCTION* pp symbols, but those are compile time substitutions not preprocessor subs. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
That should be 14.7.1 :-) I've added a test to static_assert to see if other compilers have this problem.
This failure only worries me because it's likely hiding either a bunch of other failures, or successes. So if anyone has some idea on how to make a macro generate different code based on function or non-function context I would _love_ to know.
Aha, fixed it!! There is now a custom version of static_assert for CW-8.x: // special version for CodeWarrior <= 8.x #define BOOST_STATIC_ASSERT( B ) \ BOOST_STATIC_CONSTANT(int, \ BOOST_JOIN(boost_static_assert_test_, __LINE__) = \ sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >) ) Which, for example, translates to: static const int boost_static_assert_test_10 = sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( N < 2 ) >) ; This forces the template instantiation on both function and non-function context. So for the first time all static_assert tests pass for this compiler :-) -- And this should also clear all the Spirit tests. Enjoy. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Aha, fixed it!! -- And this should also clear all the Spirit tests.
Well go figure... Because of the solution it causes redefinition errors in the Spirit tests :-( How painful. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Rene Rivera wrote:
Aha, fixed it!! -- And this should also clear all the Spirit tests.
Well go figure... Because of the solution it causes redefinition errors in the Spirit tests :-( How painful.
oh bummer! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Rene Rivera wrote:
Rene Rivera wrote:
Aha, fixed it!! -- And this should also clear all the Spirit tests.
Well go figure... Because of the solution it causes redefinition errors in the Spirit tests :-( How painful.
oh bummer!
I'm willing to use a BOOST_STATIC_ASSERT_FUNCTION or something if there's no solution in sight. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Rene Rivera wrote:
Aha, fixed it!!
There is now a custom version of static_assert for CW-8.x:
// special version for CodeWarrior <= 8.x #define BOOST_STATIC_ASSERT( B ) \ BOOST_STATIC_CONSTANT(int, \ BOOST_JOIN(boost_static_assert_test_, __LINE__) = \ sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >) )
Which, for example, translates to:
static const int boost_static_assert_test_10 = sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( N < 2 ) >) ;
This forces the template instantiation on both function and non-function context. So for the first time all static_assert tests pass for this compiler :-) -- And this should also clear all the Spirit tests.
Wow! Thanks a bunch! Rene! Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
That should be 14.7.1 :-) I've added a test to static_assert to see if other compilers have this problem.
This failure only worries me because it's likely hiding either a bunch of other failures, or successes. So if anyone has some idea on how to make a macro generate different code based on function or non-function context I would _love_ to know.
Aha, fixed it!!
There is now a custom version of static_assert for CW-8.x:
// special version for CodeWarrior <= 8.x #define BOOST_STATIC_ASSERT( B ) \ BOOST_STATIC_CONSTANT(int, \ BOOST_JOIN(boost_static_assert_test_, __LINE__) = \ sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >) )
Which, for example, translates to:
static const int boost_static_assert_test_10 = sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( N < 2 ) >) ;
This forces the template instantiation on both function and non-function context. So for the first time all static_assert tests pass for this compiler :-) -- And this should also clear all the Spirit tests.
As you've noticed already, if a static assert appears on the same line in two different files then you get a redefinition error. I don't suppose CW supports __COUNTER__ like MSVC does, if so we could give each a unique name? Failing that, there is a recommendation in the static assert docs, that users take care to place static asserts on separate lines (some compilers can't cope with duplicate typedefs, even though they are allowed in the language), can spirit be re-jigged to do that? John.
John Maddock wrote:
That should be 14.7.1 :-) I've added a test to static_assert to see if other compilers have this problem.
This failure only worries me because it's likely hiding either a bunch of other failures, or successes. So if anyone has some idea on how to make a macro generate different code based on function or non-function context I would _love_ to know.
Aha, fixed it!!
There is now a custom version of static_assert for CW-8.x:
// special version for CodeWarrior <= 8.x #define BOOST_STATIC_ASSERT( B ) \ BOOST_STATIC_CONSTANT(int, \ BOOST_JOIN(boost_static_assert_test_, __LINE__) = \ sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >) )
Which, for example, translates to:
static const int boost_static_assert_test_10 = sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( N < 2 ) >) ;
This forces the template instantiation on both function and non-function context. So for the first time all static_assert tests pass for this compiler :-) -- And this should also clear all the Spirit tests.
As you've noticed already, if a static assert appears on the same line in two different files then you get a redefinition error. I don't suppose CW supports __COUNTER__ like MSVC does, if so we could give each a unique name? Failing that, there is a recommendation in the static assert docs, that users take care to place static asserts on separate lines (some compilers can't cope with duplicate typedefs, even though they are allowed in the language), can spirit be re-jigged to do that?
Certainly. That is, if I know which of the static asserts calls is causing the troubles. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
John Maddock wrote:
As you've noticed already, if a static assert appears on the same line in two different files then you get a redefinition error. I don't suppose CW supports __COUNTER__ like MSVC does, if so we could give each a unique name?
It doesn't.. I've wished for that many times.
Failing that, there is a recommendation in the
static assert docs, that users take care to place static asserts on separate lines (some compilers can't cope with duplicate typedefs, even though they are allowed in the language), can spirit be re-jigged to do that?
Well since this is only a problem at the namespace scope, it can also be solved by wrapping with "namespace { ... }" AFAICT.
Certainly. That is, if I know which of the static asserts calls is causing the troubles.
Since the metacomm tests ran with the changed code you it's all the current failures listed on the results for Spirit/cw-8_3. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Joel de Guzman wrote:
John Maddock wrote:
As you've noticed already, if a static assert appears on the same line in two different files then you get a redefinition error. I don't suppose CW supports __COUNTER__ like MSVC does, if so we could give each a unique name?
It doesn't.. I've wished for that many times.
Failing that, there is a recommendation in the
static assert docs, that users take care to place static asserts on separate lines (some compilers can't cope with duplicate typedefs, even though they are allowed in the language), can spirit be re-jigged to do that?
Well since this is only a problem at the namespace scope, it can also be solved by wrapping with "namespace { ... }" AFAICT.
Certainly. That is, if I know which of the static asserts calls is causing the troubles.
Since the metacomm tests ran with the changed code you it's all the current failures listed on the results for Spirit/cw-8_3.
Ok. Fixed. I hope it works. I'm waiting for the next test run. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Rene Rivera wrote:
Joel de Guzman wrote:
Certainly. That is, if I know which of the static asserts calls is causing the troubles.
Since the metacomm tests ran with the changed code you it's all the current failures listed on the results for Spirit/cw-8_3.
Ok. Fixed. I hope it works. I'm waiting for the next test run.
All the Spirit tests now pass for me.. Awesome :-) Thanks, Joel. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Which is a compile-fail test, but compiles successfully with CW-8.3. I narrowed the problem down to this minimal test..
What happens if you bump up the version check in: #if !defined(BOOST_BUGGY_INTEGRAL_CONSTANT_EXPRESSIONS) && \ !BOOST_WORKAROUND(__MWERKS__, < 0x3003) In static_assert.hpp? John.
John Maddock wrote:
Which is a compile-fail test, but compiles successfully with CW-8.3. I narrowed the problem down to this minimal test..
What happens if you bump up the version check in:
#if !defined(BOOST_BUGGY_INTEGRAL_CONSTANT_EXPRESSIONS) && \ !BOOST_WORKAROUND(__MWERKS__, < 0x3003)
In static_assert.hpp?
Tried that before asking :-) -- Doesn't help. I think Peter hit it on the nail. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
participants (4)
-
Joel de Guzman -
John Maddock -
Peter Dimov -
Rene Rivera