"disable warning 4756" not disabling warning 4756
-
What am I doing wrong?
-
-
Could be that the the compiler is internally associating the warning with wherever
INFINITY
is defined? Try putting the#pragma
s around the include of<cmath>
(and move that include up so you know it's not being included from somewhere else.That's speculation, it probably won't work. But worth a shot. :-)
-
And you have tried cleaning and rebuilding ? I've found this sometimes fixes weird VS errors. (that or restarting VS)
-
Not disabling warning 4756?
Clearly he's got "not disabling" down pat. It's disabling that he's doing wrong.
Also, there are some warnings that are "undisableable" for the linker at least: http://www.geoffchappell.com/studies/msvc/link/link/options/ignore.htm
The compiler might have it's own list of undisableable warnings?
-
Tried that just now. Same warnings.
-
some warnings that are "undisableable"
Why would "you assigned INFINITY from the standard library to a float variable" be undisableable?
-
This post is deleted!
-
-
This post is deleted!
-
<img src="/uploads/default/20311/5e91239fe1051be2.png" width="598" height="500">
What am I doing wrong?
MSDN say's you're overflowing the float:
-
How should I know? I didn't write the compiler. I just know that the linker has warnings that don't go away even if you explicitly tell the linker to ignore those warnings, even when linking with "treat warnings as errors". I would expect the compiler and linker to have been designed and built by related teams, so it's reasonable to expect that what applies to one group applies to the other.
Anyway, now that I have some more time, I looked into the issue. From cppreference:
If the implementation does not support floating-point infinities, the macro INFINITY expands to a positive value that is guaranteed to overflow a float at compile time, and the use of this macro generates a compiler warning.
So it seems INFINITY in your implementation is not supported. It may be that the compiler doesn't disable standard mandated warnings.You should use the more portable numeric_limits::infinity() You can check that it's valid with std::numeric_limits<T>::has_infinity == true
-
std::numeric_limits<float>::infinity();
?
-
Out of curiosity, what are you changing in Alien Swarm's director?
-
I'm adding a new type of spawner so instead of saying "I want an asw_drone spawned here with such and such animation" you can say "this is a railing, have fun".
-
Yup, buddy's & Kian's answer seems to get rid of the warning.
`#define INFINITY ((float)(_HUGE_ENUF * _HUGE_ENUF)) /* causes warning C4756: overflow in constant arithmetic (by design) */`
Now, I think that the "by design" part doesn't make sense. The standard says "[INFINITY] expands to a constant expression of type float representing positive or unsigned infinity, if available..." and nothing about a diagnostic in that case, and I don't know of a good reason for wanting one, especially at the
/W2
level.I also don't know why the
#pragma
doesn't disable it -- but it does disable it if you surround the{
opening the function body containing the use ofINFINITY
...#include <cmath> int main() #pragma warning (push) #pragma warning (disable:4756) { #pragma warning (pop) float x = INFINITY; // no warning as-is return 0; }
So, uh, you could do that too.
-
"So, uh, you could do that too."
It would quiet the warning, but it would also do the wrong thing. He wants the float infinity value, and that warning specifically means "this is not the infinity value" according to cppreference (i don't know how to search for things in the standard, so i don't know what it says about it).
-
What am I doing wrong?
oh, this is an interesting one.
"For warning numbers in the range 4700-4999, which are the ones associated with code generation, the state of the warning in effect when the compiler encounters the open curly brace of a function will be in effect for the rest of the function. Using the warning pragma in the function to change the state of a warning that has a number larger than 4699 will only take effect after the end of the function."
-
He wants the float infinity value, and that warning specifically means "this is not the infinity value" according to cppreference
No. That quote you posted says "if infinity is not supported, it will produce a warning." It does not say "if infinity is supported, it will not produce a warning". That is why it is not in conflict.It does say that if infinity is supported then
INFINITY
needs to evaluate to it; and soINFINITY
andnumeric_limits<float>::infinity()
must be the same. And of course they are;INFINITY == numeric_limits<float>::infinity()
is true.
-
All Ben needs to do is
#PRAGMA VS_DISABLE_REAL(4756)
-
No. That quote you posted says "if infinity is not supported, it will produce a warning." It does not say "if infinity is supported, it will not produce a warning". That is why it is not in conflict.
Also, 4756 is "overflow in constant arithmetic - The compiler generated an exception while doing constant arithmetic during compilation.". So, if the definition is as you mentioned above, this would occur.
On the other hand,
std::numeric_limits<float>::infinity()
wouldn't do any arithmetic, but just return a value representing infinity (if supported by the type - and yes, floats do support it). So that would avoid the warning, while still generating the correct value.tl;dr: use
numeric_limits<>
.Edit: If you for some reason need to avoid infinities, there's also
numeric_limits<>::max()
, the largest representable finite positive value.
-
So it seems INFINITY in your implementation is not supported
IEEE-754 has been around for how long now?
Now, I think that the "by design" part doesn't make sense. The standard says "[INFINITY] expands to a constant expression of type float representing positive or unsigned infinity, if available..."
I'd file a bug on this one -- the C library shouldn't be causing the compiler to emit a diagnostic every timeINFINITY
is used in a program! (I concur with the suggestion to usestd::numeric_limits<float>::infinity()
though --INFINITY
apparently is not standard C...)
-
All Ben needs to do is
#PRAGMA VS_DISABLE_REAL(4756)
Sure, and there's a documented way to do that, even: move the #pragma above the function call. If that's bothersome, he can refactor the particular assignments into their own function, or even go crazy and refactor the entire program into a bunch of one-statement functions.
-
A long time. But don't worry, it is supported, it just produces a warning for some, probably stupid, reason.So it seems INFINITY in your implementation is not supported
IEEE-754 has been around for how long now?
It is in C99 and imported by reference in C++11. (Both according to the draft standard, since I only have the official version of C++98/03.)INFINITY
apparently is not standard C
-
It is in C99 and imported by reference in C++11. (Both according to the draft standard, since I only have the official version of C++98/03.)
Ah, I was looking in the wrong header file :P so it's an even bigger bug than I thought -- using a standard-defined macro shouldn't trigger a diagnostic message from the compiler!
Imagine the outrage that'd ensue if
getchar()
threw a warning every time it was used...
-
Ah, I was looking in the wrong header file :P so it's an even bigger bug than I thought -- using a standard-defined macro shouldn't trigger a diagnostic message from the compiler!
Imagine the outrage that'd ensue if
getchar()
threw a warning every time it was used...There are a number of standard-defined functions that trigger warnings when used on Windows anyway. Because reasons.