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

From: Pavel Kuznetsov (pavel_at_[hidden])
Date: 2003-09-30 12:11:03

David Abrahams (dave_at_[hidden]) wrote:

>> warning C4668: '...' is not defined as a preprocessor macro,
>> replacing with '0' for '#if/#elif'

DA> It shouldn't *be* a problem in the first place.  Undefined symbols
DA> are supposed to be expanded to 0 in preprocessor comparisons
DA> according to the standard.  

I agree with your interpretation of the behavior mandated by the
standard, though of course a compiler is not compromising its conformance
issuing a warning here.

DA> This is not an edge case. I think that warning should be turned off.

It is rather useful when it comes to detecting translation units where
a header file with definition of some particular macro was forgot to be
included into. So usually we keep this warning on in our projects just
for that purpose. And everything was compiled quietly while we haven't
included boost/bind.hpp.

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

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

That was not an assertion, but rather just a guess just in case that
usage of #if defined(__SUNPRO_CC) in the line mentioned:

  #if defined(__SUNPRO_CC) && BOOST_WORKAROUND(__SUNPRO_CC, <= 0x530)

is not intended to keep compiler from issuing this kind of warning.

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

DA> Where? 

Right in the files involved. boost/config.hpp or something similar
would be ok too though then your question arises:

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

Of course not, that would be not acceptable for users who turn that
warning on like our shop does. It could be rather simple to turn it
back on if boost would use guarding headers like STLport's _prolog.h
and _epilog.h. Though that is not the case...

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

DA> There's no way to do that, AFAIK.

Yes, you are right, I was too lazy to think this alternative in full
before writing first message.

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

DA> The latter, if you can find a conforming way to do it...

Well, as turned out in fact I can not do it.

So now I see these alternatives to keep that warning quiet:

1) Require checking whether symbol is defined before using
BOOST_WORKAROUND. Not that good thing since it compromises the very
purpose of this macro. Currently involves about 240 replacements in
about 95 header files across all the boost libraries. Ugh, of course
nobody will like it.

2) Guard all the headers in question with #pragmas. Requires
modification of about 60 header files.

3) Provide some kind of prolog/epilog header files and encapsulate
the code switching and restoring the warning(s) back on there. Somewhat
better than (2), though of course it is not perfect. One of the
advantages of this approach is its scalability: if there will be a need
for the boost to say suppress some another warning across all the library
files it always will be possible to just include the code in those files.
Efforts required are about the same as in (2).

4) Forget modifying boost and manage the problem mentioned on the
client side. Involves providing forwarding headers for about 60 of
the boost headers. Efforts required are about the same as in (1) and (2)
but multiplied by the number of users who does it. On the other hand
it seems that so far I am the first who is
concerned about the problem, am I not?..

Given this I would prefer to do the job required for (3), but if the
boost community will oppose, I'll go (4).

What do you think?

--
Pavel