[foreach] Warning with gcc-4.6.0 and -Wconversion

[sefi@…]

gcc-4.6.0 made Boost.foreach unusable in 1.46.1 because the rvalue detection no longer works. Now, there is a fix in trunk for it but it has a nasty side effect, namely a warning that is emitted whenever foreach is used with an rvalue and -Wconversion is turned on. Sadly, this warning cannot be ignored by including Boost with -isystem because the code is generated by a macro, obviously.

I would be glad if this could be fixed somehow because -Wconversion is a crucial warning option to me.

[sefi@…]

Testcase

[sefi@…]

Warning output

[anonymous]

See also: ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49021#c12, where a related problem is discussed, the final resolution is pointing to a bug in BOOST_FOREACH_COMPILE_TIME_CONST_RVALUE_DETECTION.

[Eric Niebler]

I believe gcc is warning about perfectly valid code. There is no other way to detect const rvalues in C++98 that I'm aware of. I don't know how to fix this, and using _Pragma to suppress the warning didn't work. I'm sorry, I don't think this is fixable.

If you come up with a patch, please reopen this ticket. Thanks.

[anonymous]

For what it's worth, I found a workaround this way. I'm assuming the compiler will optimize out the vLINE variables. The LINE concatenation is required if you have multiple FOREACH calls with\in the same scope.

#if defined(__GNUC__)
#define M_FOREACH(elem, vec)    M_FOREACH_W_LINE(elem,vec,__LINE__)
#define M_FOREACH_W_LINE(elem, vec, n) M_FOREACH_CONCAT_VAR(elem, vec, n)
#define M_FOREACH_CONCAT_VAR(elem, vec, n)              \
        __typeof__(vec) v ## n = vec;                   \
        BOOST_FOREACH(elem, v ## n)

#else
#define M_FOREACH(elem, vec)                            \
        BOOST_FOREACH(elem, vec)
#endif

[anonymous]

Replying to eric_niebler:

I believe gcc is warning about perfectly valid code. There is no other way to detect const rvalues in C++98 that I'm aware of. I don't know how to fix this, and using _Pragma to suppress the warning didn't work. I'm sorry, I don't think this is fixable.

If you come up with a patch, please reopen this ticket. Thanks.

Reopened, see previous comment

[Steven Watanabe]

Replying to anonymous:

I'm assuming the compiler will optimize out the vLINE variables.

It's extremely unlikely. This workaround is also completely unsuitable for inclusion in the library.