Re: [boost] Supressing warnings

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-06-30 08:33:33

Paul A Bristow wrote:
>  
> 
> |  -----Original Message-----
> |  From: boost-bounces_at_[hidden] 
> |  [mailto:boost-bounces_at_[hidden]] On Behalf Of Yuval Ronen
> |  Sent: 29 June 2006 20:55
> |  To: boost_at_[hidden]
> |  Subject: Re: [boost] Supressing warnings
> |  
> |  Paul A Bristow wrote:
> |  > IMO Boost-worthy code should be able to be compiled in 
> |  strict mode, for MSVC
> |  > level 4, without producing a blizzard of warnings.
> |  > 
> |  > Including a list of warnings that the authors of the 
> |  library consider
> |  > unhelpful, and in some cases, unfixable (specifically the warning
> |  > "conditional expression is constant. ")
> |  > 
> |  > by using, for example
> |  > 
> |  > #ifdef _MSC_VER
> |  > #  pragma warning(disable: 4127) // conditional expression 
> |  is constant. 
> |  > #endif
> |  
> |  This warning is not so bad, IMO. It tells you that you are trying 
> |  evaluate a compile-time constant in run-time, and that's wasting CPU 
> |  cycles. The runtime 'if' can be substituted by a compile-time 
> |  specialization.
> 
> <snip>
> 
> If I now write (a VERY common example)
> 
>    if(std::numeric_limits<T>::has_infinity)
>       return std::numeric_limits<T>::infinity();
> 
> It IS I believe a C++ language fault, that has_infinity doesn't work like a
> macro constant,
> 
> described by Bjarne Stroustrup as "an embarassment",
> 
> (a TODO for C++0X but reference to which escapes me at present).

Isn't std::numeric_limits<T>::has_infinity a compile-time constant? I 
thought it is... MSDN certainly describes it as such, but of course MSDN 
might be not that strict when it comes to following the standard...

> What in this type of case are you suggesting that I write for the time
> being?

Exactly what I was suggesting before. Use an 'if' statement for runtime 
values, and template specialization for compile-time constants. The fact 
that std::numeric_limits<T>::has_infinity is or is not a standard 
defect, doesn't change anything.

> And since it is VERY common, it had better be short ;-)

If you claim is that performance should be sacrificed a bit for the sake 
of brevity, than it's something completely different. You can sure 
justify it for some of the people, sometimes, but for all of the people, 
all of the time? That's a bit too much IMO. For those cases where it's 
justified, it can be disabled.

> MACROs just about allowed!

I have to admit I didn't understand this, sorry...

> PS If I write
> 
> if(true) ...
> 
> I'm not sure why I need a warning about it :-)

Well, if you had replaced 'true' with 
'a-constant-evaluated-from-a-very-complex-meta-programming', then I'd 
say the reason is the performance loss I was talking about before. But 
since it's a simple 'true', it's even more obvious than this - because 
it's weird. Are you saying that writing 'if (true) ...' is considered 
good coding? Nobody should write code like this, because it clearly 
doesn't reflect the real logic that it performs. If I were a compiler, 
and I had a bad day at work, I'd issue an error for this... ;-)