Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Curiosity about compiler warnings


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 Plethora   Members   -  Reputation: 683

Like
0Likes
Like

Posted 26 March 2013 - 10:51 AM

So I've read before that its general good practice to take care of compiler warnings whenever possible and that makes sense to me and I do so as much as I can, but I run into some of them every so often that don't really make sense to me.  Such as:

 

conversion from 'int' to 'float', possible loss of data

 

Firstly, how would I lose data if I'm going from int to float?  Obviously if I was going from float to int I would potentially lose data and that wouldn't be good generally speaking, but from int to float? 

 

Secondly, the line of code referred to in my current program is taking the return value of one function (not even my function, from a library I'm using) and applying it as a parameter in another function (also not one of mine).  Would it be considered good practice to explicitly re-cast the int as a float and then use it as a parameter in this case?


I'm working on a game!  It's called "Spellbook Tactics".  I'd love it if you checked it out, offered some feedback, etc.  I am very excited about my progress thus far and confident about future progress as well!

 

http://infinityelephant.wordpress.com


Sponsor:

#2 Paradigm Shifter   Crossbones+   -  Reputation: 5525

Like
7Likes
Like

Posted 26 March 2013 - 10:57 AM

Not every int is representable as a float (assuming both are 32 bits in size). You lose precision once the mantissa runs out of bits, so you can't represent odd integers above a certain size with a float. A double should be able to represent all the ints though.

 

Use a cast to supress the warning, yes.


Edited by Paradigm Shifter, 26 March 2013 - 10:57 AM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#3 Plethora   Members   -  Reputation: 683

Like
0Likes
Like

Posted 26 March 2013 - 11:02 AM

In general, is it considered good programming practice to eliminate warning generating code at all times even when you're pretty damned sure there wouldn't ever be a problem with it?


I'm working on a game!  It's called "Spellbook Tactics".  I'd love it if you checked it out, offered some feedback, etc.  I am very excited about my progress thus far and confident about future progress as well!

 

http://infinityelephant.wordpress.com


#4 Paradigm Shifter   Crossbones+   -  Reputation: 5525

Like
4Likes
Like

Posted 26 March 2013 - 11:04 AM

Yes, because you might miss new warnings that pop up if you ignore them, especially if there are a lot of them.

 

You can disable specific warnings if you need to with a #pragma (#pragma warning(disable:NNNN) in Visual Studio).


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#5 Cornstalks   Crossbones+   -  Reputation: 6995

Like
9Likes
Like

Posted 26 March 2013 - 11:05 AM

I suggest you read up on how IEEE 754 floating point variables work. I'll explain things simply (assuming 32 bit float and 32 bit int):

 

int has 32 bits and can represent any integer between -2147483648 and +2147483647

float has 32 bits, but they're used differently. 1 bit is for the sign (positive or negative), 8 bits are for the exponent (so if you write it in scientific form: number * 2exponent, these 8 bits store the exponent), and 23 bits for the mantissa (the number part).

 

In short, you've only got 23 bits of precision to work with when trying to represent a number in floating point. The other 9 bits have nothing to do with precision (they just determine positive/negative and magnitude, but not precision).

 

int, on the other hand, has 32 bits of precision to work with. You can't stuff 32 bits of precision into 23 bits without expecting to lose some precision. Hence, you get a warning.

 

A 32 bit float only gives you 6 decimal digits of guaranteed precision. int, on the other hand, gives you 9 decimal digits of guaranteed precision.

 

To test it out, try the following:

#include <iostream>
 
int main()
{
    std::cout.precision(50); // print out a ton of digits
 
    int i = 1234567890;
    float f = (float)i;
 
    std::cout << i << std::endl;
    std::cout << f << std::endl;
}

 

For me it prints out:

1234567890
1234567936

 

Notice how the first 7 decimal digits of the float are correct, and after that they're bogus. The warning is there to let you know you might lose some data. If you explicitly cast (like I did), it eliminates the warning because it tells the compiler "Look, I know they're not the same data type and that I might lose some data, but this is what I really want to do; it's not a mistake."


Edited by Cornstalks, 26 March 2013 - 11:14 AM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#6 mhagain   Crossbones+   -  Reputation: 8986

Like
4Likes
Like

Posted 26 March 2013 - 11:27 AM

Re: floats, see http://www.altdevblogaday.com/2012/02/05/dont-store-that-in-a-float/ - the section headed "Tables" about two-fifths down the page summarises floating point precision losses at various ranges.  So long as the precision loss is sufficiently low (i.e under 1) it's probably not a problem (but be absolutely certain that your data is going to fall in this safe range!) but what's interesting is that there are ranges where the precision loss becomes higher than 1, and that these ranges are well within the capacity of a 32-bit signed int.  So, for values over about 10,000,000 or so, you will lose data by converting from int to float.

 

Re: warnings, all that they are is the compiler giving you a heads-up that the code you're using is potentially suspicious.  They're neither exhaustive nor prescriptive, but despite that I personally consider it good practice to compile with a reasonably high warning level (2 or 3; going all the way to 4 may be too much as it may throw warnings for otherwise perfectly fine code, such as "while (1)" for infinite loops, for example) and always compile with warnings as errors.  Do this early enough in the development process and it gets you into the habit of writing good clean code from the outset.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#7 Plethora   Members   -  Reputation: 683

Like
0Likes
Like

Posted 26 March 2013 - 11:44 AM

Well, the line of code in question is referring the the X'th pixel of a 32x32 image, so I think in this case I'm safe since if it falls in the range where there could be a problem... well there would be far more serious issues with my code if that happens, lol.

 

But point taken on the general case, thanks for the answers all.  :)


I'm working on a game!  It's called "Spellbook Tactics".  I'd love it if you checked it out, offered some feedback, etc.  I am very excited about my progress thus far and confident about future progress as well!

 

http://infinityelephant.wordpress.com


#8 Hodgman   Moderators   -  Reputation: 36314

Like
2Likes
Like

Posted 26 March 2013 - 08:39 PM

So I've read before that its general good practice to take care of compiler warnings whenever possible

On a few of the commercial projects I've worked on, they've enabled the highest level of warnings, and also enabled "treat warnings as errors" so that your code won't build if there's any errors.
They've also then had a system where you cannot commit your code into the central repository if it doesn't build, which forces people to always fix their warnings immediately wink.png



#9 Aldacron   GDNet+   -  Reputation: 3395

Like
1Likes
Like

Posted 27 March 2013 - 12:11 AM

In general, is it considered good programming practice to eliminate warning generating code at all times even when you're pretty damned sure there wouldn't ever be a problem with it?

 

The reasons warnings exist is to let you know that you've done something potentially problematic. The compiler doesn't know if you did it intentionally or not. The warning gives you the opportunity to clarify. If it *is* intentional, then you can add a cast or whatever else you need to do so that the compiler, and other programmers, can understand it's what you wanted to do. If it was a mistake, you can change the offending code to something else. Fixing warnings is considered good practice because it makes your code easier to reason about. But you shouldn't do so blindly. You have to always be aware of the parameters surrounding the offending code. Things like truncation, signed/unsigned comparisons, and so on can come back and bite you later on down the road even if you are using it intentionally, especially as the code base evolves and lines are added and removed.



#10 irreversible   Crossbones+   -  Reputation: 1512

Like
2Likes
Like

Posted 27 March 2013 - 03:50 AM

A long time ago as I was writing a graph drawing class and wanted some method to test it, I ended up writing a method to plot precision ranges for floating point numbers. Here are the linear and logarithmic displays of 32, 64 and 80 bit floating point numbers graphed exponent vs minimum precision (step). I find them useful to look at every now and then.

 

fpPrecisionLin.jpg

fpPrecisionLog.jpg






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS