[boost] Re: MSVC++ warnings in boost headers (mem_fn.hpp)

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-30 09:12:17

"Pavel Kuznetsov" <pavel_at_[hidden]> writes:

> It seems that boost code is written to avoid compilers warnings. Though
> some warnings do slip into MSVC++ builds when boost headers are included.
> Most (all?) of these are the warnings which are turned of by default. In
> particular sometimes I can see C4668 warnings shown:
>
>   boost\boost\mem_fn.hpp(296) : warning C4668:
>     '__MWERKS__' is not defined as a preprocessor macro,
>     replacing with '0' for '#if/#elif'
>
> Where boost\boost\mem_fn.hpp(296) is:
>
>   #if !BOOST_WORKAROUND(BOOST_MSVC, <= 1300) && 
>       !BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3003))
>
> Where BOOST_WORKAROUND is:
>
>   #  define BOOST_WORKAROUND(symbol, test)                \
>           ((symbol != 0) && (1 % (( (symbol test) ) + 1)))
>
> It seems that in some places authors are aware of the problem
> stated.

It shouldn't *be* a problem in the first place.  Undefined symbols are
supposed to be expanded to 0 in preprocessor comparisons according to
the standard.  This is not an edge case.  I think that warning should
be turned off.

> E.g.: boost\boost\intrusive_ptr.hpp(124):
>
>   #if defined(__SUNPRO_CC) && BOOST_WORKAROUND(__SUNPRO_CC, <= 0x530)

The BOOST_WORKAROUND macro is specifically designed to avoid having
to repeat that sort of boilerplate code.

> (Of course it is possible that in fact __SUNPRO_CC can be defined to 0 and
> it is that case what is tested here...)

I have real doubts about that assertion.  How do you know that's
what's being tested for?  I've never seen a vendor #define a symbol
like __SUNPRO_CC to zero.

> So I see two ways to eliminate the warning in question: either suppress it
> with corresponding #pragmas

Where?  Do you suggest we do that without turning the warning back on?

> or rewrite BOOST_WORKAROUND so that it would
> test whether 'symbol' is defined before comparing it to 0.

There's no way to do that, AFAIK.

> I could submit the patches for either of these. Which one do you
> prefer?

The latter, if you can find a conforming way to do it... but I'm
pretty sure it's impossible.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com