Boost C++ Libraries: Ticket #5522: [foreach] Warning with gcc-4.6.0 and -Wconversion

attachment set

sefi@… — Thu, 05 May 2011 15:29:53 GMT

attachment → test.cpp

Testcase

attachment set

sefi@… — Thu, 05 May 2011 15:30:58 GMT

attachment → output.log

Warning output

anonymous — Mon, 23 May 2011 08:42:14 GMT

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.

status changed; resolution set

Eric Niebler — Sun, 29 May 2011 15:35:25 GMT

status new → closed
resolution → wontfix

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 — Tue, 18 Feb 2014 20:39:43 GMT

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

status, type changed; resolution deleted

anonymous — Tue, 18 Feb 2014 20:42:35 GMT

status closed → reopened
type Bugs → Patches
resolution wontfix

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

status changed; resolution set

Steven Watanabe — Fri, 04 Apr 2014 18:34:26 GMT

status reopened → closed
resolution → wontfix

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.