Jump to content
  • Advertisement
Sign in to follow this  
Red Ant

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

This topic is 2542 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


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

Share this post


Link to post
Share on other sites
That doesn't make any sense. If the compiler can optimize it out of a function it can optimize it out of a define.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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):
"[font="Georgia"]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
[/font]

Share this post


Link to post
Share on other sites

One note on style, regarding the const-qualified bool return-type (note: bool is a built-in type):
"[font="Georgia"]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
[/font]


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

.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!