"disable warning 4756" not disabling warning 4756

ben_lubar

What am I doing wrong?

loopback0

@ben_lubar said:

What am I doing wrong?

Not disabling warning 4756?

Filed under: INB4 Alien Swarm

EvanED

Could be that the the compiler is internally associating the warning with wherever INFINITY is defined? Try putting the #pragmas 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. :-)

swayde

And you have tried cleaning and rebuilding ? I've found this sometimes fixes weird VS errors. (that or restarting VS)

Kian

@loopback0 said:

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?

ben_lubar

Tried that just now. Same warnings.

ben_lubar

@Kian said:

some warnings that are "undisableable"

Why would "you assigned INFINITY from the standard library to a float variable" be undisableable?

blakeyrat

This post is deleted!

ben_lubar

http://what.thedailywtf.com/t/people-being-dicks-in-coding-help-suck/47903

blakeyrat

This post is deleted!

rad131304

@ben_lubar said:

<img src="/uploads/default/20311/5e91239fe1051be2.png" width="598" height="500">

What am I doing wrong?

MSDN say's you're overflowing the float:

Archiveddocs

Compiler Warning (level 2) C4756

Kian

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

Buddy

std::numeric_limits<float>::infinity();?

powerlord

Out of curiosity, what are you changing in Alien Swarm's director?

ben_lubar

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".

EvanED

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 of INFINITY...

#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.

Kian

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

FrostCat

@ben_lubar said:

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."

See https://msdn.microsoft.com/en-us/library/2c8f766e.aspx

EvanED

@Kian said:

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 so INFINITY and numeric_limits<float>::infinity() must be the same. And of course they are; INFINITY == numeric_limits<float>::infinity() is true.

sloosecannon

All Ben needs to do is

#PRAGMA VS_DISABLE_REAL(4756)

cvi

@EvanED said:

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.

tarunik

@Kian said:

So it seems INFINITY in your implementation is not supported

IEEE-754 has been around for how long now?

@EvanED said:

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 time INFINITY is used in a program! (I concur with the suggestion to use std::numeric_limits<float>::infinity() though -- INFINITY apparently is not standard C...)

FrostCat

@sloosecannon said:

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.

EvanED

@tarunik said:

So it seems INFINITY in your implementation is not supported

IEEE-754 has been around for how long now?

A long time. But don't worry, it is supported, it just produces a warning for some, probably stupid, reason.

@tarunik said:

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

tarunik

@EvanED said:

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

dkf

@tarunik said:

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.