Boost logo

Boost :

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:
> # 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at