I have raised this issue before, inconclusively, but the question has now become more urgent now that I am packaging some math functions produced by John "Doing the Impossible" Maddock. 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. # pragma warning(disable: 4100) // unreferenced formal parameter. # pragma warning(disable: 4512) // assignment operator could not be generated. # pragma warning(disable: 4996) // 'std::char_traits<char>::copy' was declared deprecated. // needed ifndef _SCL_SECURE_NO_DEPRECATE or == 0 // #define _SCL_SECURE_NO_DEPRECATE = 1 // Avoid C4996 warning. // #define _SCL_SECURE_NO_DEPRECATE = 0 // get C4996 warning. #endif is fine for that package, but also supresses these warnings for other code, which users rightly object to. It also doesn't help other platforms, except to list the ignorable warnings. Pushing and poping warning levels is VERY tedious, and almost impractiable, and doesn't help non-MSVC platforms. What is the best way to deal with this? Is it to provide for MSVC includable files, say math_strict.hpp, test_strict.hpp, filesystem_strict.hpp ... containing the above (tailored for the library, if necessary)? What about other platforms? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
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. E.g, instead of if (compile-time-bool-constant) { ... } else { ... } you can write: template <bool Cond> void foo(...); template <> void foo<false>(...) { ... } template <> void foo<true>(...) { ... } ... foo<compile-time-bool-constant>(...); or something similar. This will prevent the compiler from generating the runtime comparison. Sure this is a small piece of code we are trying to optimize, and a good optimizing compiler would remove it anyway, but if we can write more efficient code without relying on a compiler optimization that might or might not be there, isn't it better? Yuval P.S. if someone really insists on suppressing this warning, but doesn't like my suggestion, he could probably write (untested if this really works) bool b = compile-time-bool-constant; if (b) { ... } else { ... } although I really don't like it...
On 6/29/06, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
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.
[...]
This will prevent the compiler from generating the runtime comparison. Sure this is a small piece of code we are trying to optimize, and a good optimizing compiler would remove it anyway, but if we can write more efficient code without relying on a compiler optimization that might or might not be there, isn't it better?
Surely if a compiler is smart enough to know that a conditional is constant then it should be able to get rid of the test-and-branch anyways. I know that g++ can resolve an if ( boost::is_signed<T>::value ) at compile-time and only emit code for the branch that is taken. And, of course, it doesn't have this warning. ~ Scott McMurray
me22 wrote:
On 6/29/06, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
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.
[...]
This will prevent the compiler from generating the runtime comparison. Sure this is a small piece of code we are trying to optimize, and a good optimizing compiler would remove it anyway, but if we can write more efficient code without relying on a compiler optimization that might or might not be there, isn't it better?
Surely if a compiler is smart enough to know that a conditional is constant then it should be able to get rid of the test-and-branch anyways.
You're probably right, but Microsoft, perhaps unintentionally, produced a warning that helps us generate more portable code - code that doesn't rely on optimizations present on specific compilers. The question is "do we want to rely on such optimizations when writing portable code?" I'm not saying the answer is "No", or even that there is an absolute answer; I just raised the question...
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Yuval Ronen | Sent: 29 June 2006 20:55 | To: boost@lists.boost.org | 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). What in this type of case are you suggesting that I write for the time being? And since it is VERY common, it had better be short ;-) MACROs just about allowed! Thanks Paul PS If I write if(true) ... I'm not sure why I need a warning about it :-) --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On Fri, 30 Jun 2006 10:43:17 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:
[...]
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,
That is? (NOTE: perhaps I'm wrong but this seems a discussion for c.l.c++.moderated --has it to do with boost?) --Gennaro.
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennaro Prota | Sent: 30 June 2006 12:37 | To: boost@lists.boost.org | Subject: Re: [boost] Supressing warnings | | On Fri, 30 Jun 2006 10:43:17 +0100, "Paul A Bristow" | <pbristow@hetp.u-net.com> wrote: | | > [...] | > | >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, | | That is? (NOTE: perhaps I'm wrong but this seems a discussion for | c.l.c++.moderated --has it to do with boost?) Well I originally asked for recommendations on dealing with this problem for a _Boost__ proposal. But I don't see any clear answer, except what looks a hassle, so I will thank contributers for their advice, try and take it, and shut up ;-) Thanks. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On Fri, 30 Jun 2006 13:58:49 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> wrote:
| [snip] | | That is? (NOTE: perhaps I'm wrong but this seems a discussion for | c.l.c++.moderated --has it to do with boost?)
Well I originally asked for recommendations on dealing with this problem for a _Boost__ proposal.
But I don't see any clear answer, except what looks a hassle, so I will thank contributers for their advice, try and take it, and shut up ;-)
I didn't mean for you to shut up, of course :) Just that we all try keeping on-topic for the list. --Gennaro.
Paul A Bristow wrote:
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Yuval Ronen | Sent: 29 June 2006 20:55 | To: boost@lists.boost.org | 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... ;-)
participants (4)
-
Gennaro Prota -
me22 -
Paul A Bristow -
Yuval Ronen