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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk