karma::uint_generator fails to compile in C++11 mode

[Andrey Semashev]

After the #8361 ticket has been fixed (including my syntax fix in revision [83754]) karma::uint_generator fails to compile on gcc 4.7.2 with the following error:

In file included from ./boost/spirit/include/karma_uint.hpp:16:0,
                 from karma_uint_gen.cpp:1:
./boost/spirit/home/karma/numeric/uint.hpp: In static member function ‘static bool boost::spirit::karma::any_uint_generator<T, CharEncoding, Tag, Radix>::generate(OutputIterator&, Context&, const Delimiter&, boost::spirit::unused_type)’:
./boost/spirit/home/karma/numeric/uint.hpp:290:13: error: static assertion failed: uint_not_usable_without_attribute

The attached code snippet demonstrates the problem if compiled with the following command.

g++ -std=c++0x -I"." -c karma_uint_gen.cpp -o karma_uint_gen

The code compiles fine if -std=c++0x is removed.

[Andrey Semashev]

The code snippet demonstrating the error.

[Andrey Semashev]

An additional observation. The code compiles on c++0x mode if native static_assert use is disabled in assert_msg.hpp. It looks like gcc performs the assertion failure when compiling any_uint_generator::generate because the compile time predicate is a constant false and does not depend on template parameters. For example, if I replace the line

BOOST_SPIRIT_ASSERT_MSG(false, uint_not_usable_without_attribute, ());

with

BOOST_SPIRIT_ASSERT_MSG((!is_same< OutputIterator, OutputIterator >::value), uint_not_usable_without_attribute, ());

the code compiles. I think this is a compiler bug, but a workaround is desired. Perhaps this any_uint_generator::generate overload should not be present in the first place?

[Hartmut Kaiser]

I'd appreciate if you were able to create a patch. I'd be glad to apply it.

[Andrey Semashev]

I'm not sure what's the right solution for the problem. Should the method be removed? Or should the condition be tweaked? Or is there a better way?

[Hartmut Kaiser]

Replying to andysem:

I'm not sure what's the right solution for the problem. Should the method be removed? Or should the condition be tweaked? Or is there a better way?

The main question is: why is this happening in the first place? Is it because gcc 4.7 in C++11 mode overeagerly instantiates this function without need? If this is the case, then we can't do anything than to wrap it into a proper preprocessor condition.

[Andrey Semashev]

The main question is: why is this happening in the first place? Is it because gcc 4.7 in C++11 mode overeagerly instantiates this function without need?

It seems so, although I'm not sure it instantiates the whole function and not just static_assert. I didn't dig the standard to find out whether the compiler is supposed to behave that way (seems unlikely, though).

If this is the case, then we can't do anything than to wrap it into a proper preprocessor condition.

Does the trick with is_same look like a reasonable solution to you? I searched the code, there are quite a few similar asserts on false constant scattered. I could replace such cases with a new macro with this trick, if it's ok with you.

If not, then I'm afraid, the only option is to ban static_assert for gcc, which is unfortunate.

PS: I took a closer look at the code and it looks like removing the offending functions can result in less concise error messages, so I'm not considering this option.

[Hartmut Kaiser]

Replying to andysem:

The main question is: why is this happening in the first place? Is it because gcc 4.7 in C++11 mode overeagerly instantiates this function without need?

It seems so, although I'm not sure it instantiates the whole function and not just static_assert. I didn't dig the standard to find out whether the compiler is supposed to behave that way (seems unlikely, though).

If this is the case, then we can't do anything than to wrap it into a proper preprocessor condition.

Does the trick with is_same look like a reasonable solution to you? I searched the code, there are quite a few similar asserts on false constant scattered. I could replace such cases with a new macro with this trick, if it's ok with you.

Yeah sure. If that works, it's fine.

If not, then I'm afraid, the only option is to ban static_assert for gcc, which is unfortunate.

Indeed, I agree.

PS: I took a closer look at the code and it looks like removing the offending functions can result in less concise error messages, so I'm not considering this option.

*sigh* - there isn't much we could do otherwise if the solution you suggested does not work.

[Andrey Semashev]

The patch fixes the problem by changing the assert condition.

[Andrey Semashev]

I attached the patch that resolves the original problem and also fixes the same issue in other places. I didn't test those other places though.

[Hartmut Kaiser]

(In [83776]) Fix #8381: karma::uint_generator fails to compile in C++11 mode

[Andrey Semashev]

Could you please merge it to release as well? The current assert_msg.hpp does not compile.

[Hartmut Kaiser]

Replying to andysem:

Could you please merge it to release as well? The current assert_msg.hpp does not compile.

Done.