[boost] Re: BOOST_STATIC_WARNING ?

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-06-19 23:49:42

On Wednesday, June 18, 2003, at 9:59 PM, David Abrahams wrote:

> Daryle Walker <dwalker07_at_[hidden]> writes:
>
>>>> My point was that warnings are non-portable constructions made up 
>>>> by compiler makers.
>>>
>>> So are the semantics of #include.  That doesn't mean we can't count 
>>> on certain similarities (though they may be hard to find).
>>
>> Actually, the semantics of #include aren't that made up; they are
>> constrained by standard.
>
> Slightly.  They are still "non-portable constructions made up by
> compiler makers."

As I understand it, the #include directive dumps the contents of a file 
found from the standard (<>) and/or user ("") header space.  The only 
degrees of variance is how the mapping of header names to files/sources 
occurs and how the standard headers are handled.  Equating the 
implementation-defined parts of #include to the warning concept, which 
has no official standing, is a gross misrepresentation.

> We rely on what we can count on in practice.

The difference between the theory and practice of #include can't be 
that bad, can it?  Especially compared to some other C++ issues (e.g. 
export).

>> In contrast, a compiler doesn't even have to have warnings,
>
> In practice they all do.

That doesn't mean that the warnings are effective.  Or the user may 
have them deactivated.

>> let alone define them in an easy-to-exploit manner or with any
>> similarity to other compilers.
>
> Whether they do in practice remains to be seen.
>
>> I don't want to see a big effort (i.e. a long #if/#elif chain from 
>> heck with subtle details and could break at the next release of any 
>> compiler) on something that is inherently non-portable.
>
> How about a small effort?  There aren't really all that many
> front-ends.

The amount doesn't matter; it's more of a philosophical objection.

A question towards the original presenter: why would you need a such a 
macro?  Constructs that produce a warning will do so without the macro. 
  It could be needed if:

1.	You wrote conforming code,
2.	And the code passed the compiler's warning filters,
3.	But you want it flagged as a warning anyway

Why would you write such code?  If the code passed by the warnings, it 
may be good code.  If you feel it's yucky code, then write a better 
alternative, or accept that your code actually is good enough.  
Messages that are there just to broadcast loathing of your own code 
would be distracting to the user, especially if the user can't fix the 
code.  (An user may strive to have no warnings, but can't because your 
code is in permanent warning mode.  The user could hack the header, but 
what would be the point of presenting the header if the user had to 
finish it?)

Daryle