Boost logo

Boost :

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... ;-)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk