Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


[C++] Are compilers allowed to optimize ...


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
12 replies to this topic

#1 Red Ant   Members   -  Reputation: 461

Like
0Likes
Like

Posted 20 December 2011 - 10:36 AM

the following function away?

template < typename FloatType >
inline const bool is_NaN( FloatType number )
{
	// A NaN doesn't compare equal to anything, not even itself.
	return number != number;
}

Obviously, I intend to use this to test a floating point variable for NaN (not a number) ... can't use std::isnan() because our compiler doesn't support C++11. My worry is that the compiler might optimize the whole call away, on account of comparing a number to itself being so unbelievably stupid. <_<

Sponsor:

#2 brx   Members   -  Reputation: 720

Like
3Likes
Like

Posted 20 December 2011 - 10:40 AM

We have the same method in our code and it is not optimized away (neither in visual studio nor gcc).

Just to be sure: do a little test project where you force a number to be nan (e.g. sqrt(-1) should produce nan, I think). Apply your nan check and have different output based on the result. Compile with full optimization and check the results.

#3 Cornstalks   Crossbones+   -  Reputation: 6991

Like
2Likes
Like

Posted 20 December 2011 - 10:44 AM

I wouldn't be surprised if it optimized it away for integer-type variables. For floating point, I'm not sure though; seeing as it is a pretty standard test for NaN, I would expect compiler writers to be aware of this and not optimize it away.

[edit]

If you're using MSVC++, you may be able to use _isnan(). If you're not using MSVC++ and your compiler still doesn't support C's isnan(), I pity your soul.
[ 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 ]

#4 Álvaro   Crossbones+   -  Reputation: 13649

Like
3Likes
Like

Posted 20 December 2011 - 10:50 AM

If a compiler optimizes that away, it has a bug. It cannot be optimized away precisely because of the behavior of NaNs. I think you are safe.

#5 mhagain   Crossbones+   -  Reputation: 8136

Like
-1Likes
Like

Posted 20 December 2011 - 12:21 PM

Personally I'd do this as a #define rather than a function; that way you don't need to worry about optimization or not.

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.


#6 SiCrane   Moderators   -  Reputation: 9626

Like
0Likes
Like

Posted 20 December 2011 - 12:23 PM

That doesn't make any sense. If the compiler can optimize it out of a function it can optimize it out of a define.

#7 Red Ant   Members   -  Reputation: 461

Like
0Likes
Like

Posted 20 December 2011 - 01:08 PM

If a compiler optimizes that away, it has a bug. It cannot be optimized away precisely because of the behavior of NaNs. I think you are safe.


I suspected as much, but it's good to have it confirmed by you guys. Thanks. ;)

#8 Promit   Moderators   -  Reputation: 7335

Like
2Likes
Like

Posted 20 December 2011 - 01:19 PM

You might find this article interesting: Microsoft Visual C++ Floating-Point Optimization

#9 Matt-D   Crossbones+   -  Reputation: 1467

Like
1Likes
Like

Posted 20 December 2011 - 03:24 PM

the following function away?

template < typename FloatType >
inline const bool is_NaN( FloatType number )
{
	// A NaN doesn't compare equal to anything, not even itself.
	return number != number;
}

Obviously, I intend to use this to test a floating point variable for NaN (not a number) ... can't use std::isnan() because our compiler doesn't support C++11. My worry is that the compiler might optimize the whole call away, on account of comparing a number to itself being so unbelievably stupid. <_<


One note on style, regarding the const-qualified bool return-type (note: bool is a built-in type):
"For built-in types, it doesn’t matter whether you return by value as a const, so you should avoid confusing the client programmer and leave off the const when returning a built-in type by value."
// http://linuxtopia.or...pter08_014.html


#10 Red Ant   Members   -  Reputation: 461

Like
0Likes
Like

Posted 20 December 2011 - 04:21 PM

One note on style, regarding the const-qualified bool return-type (note: bool is a built-in type):
"For built-in types, it doesn’t matter whether you return by value as a const, so you should avoid confusing the client programmer and leave off the const when returning a built-in type by value."
// http://linuxtopia.or...pter08_014.html


I'm aware of that, but I've made a habit of doing it just because it makes it impossible to write silly stuff like

is_NaN( 6.3433 ) = false;


P.S. Never mind, apparently for built-in return types the line above is always impossible to compile. So yeah, basically you're right ... I've been doing it wrong all these years. :)

.

#11 Slavik81   Members   -  Reputation: 360

Like
0Likes
Like

Posted 22 December 2011 - 06:49 PM

That NaN check might not work if you enable fp-fast or otherwise allow deviance from the floating point spec.

Just so you know.

#12 DevFred   Members   -  Reputation: 836

Like
0Likes
Like

Posted 26 December 2011 - 05:46 AM

I'm aware of that, but I've made a habit of doing it just because it makes it impossible to write silly stuff like

is_NaN( 6.3433 ) = false;

That assignment is always impossible, no matter if you return a bool or a const bool. Again, the const is simply ignored here, it doesn't make any difference whatsoever. The language simply does not allow assigning to scalar rvalues.

#13 Red Ant   Members   -  Reputation: 461

Like
0Likes
Like

Posted 26 December 2011 - 12:12 PM

That assignment is always impossible, no matter if you return a bool or a const bool. Again, the const is simply ignored here, it doesn't make any difference whatsoever. The language simply does not allow assigning to scalar rvalues.


Yes, if you read my last post you'll see that I've already conceded that point. ;)




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