Jump to content

  • Log In with Google      Sign In   
  • Create Account


Magical if-statement

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

#1 ysg   Members   -  Reputation: 192

Like
2Likes
Like

Posted 12 March 2013 - 12:15 PM

if (foo == foo || bar == bar) {
...
}
else {
...
}

This is an old one.  My software lead did this, I showed it to her and she said: Umm... I... yeah... I wasn't thinking :) .

 

We both laughed and I rewrote it all :) .



Sponsor:

#2 C0lumbo   Crossbones+   -  Reputation: 2133

Like
6Likes
Like

Posted 12 March 2013 - 12:28 PM

If it's a floating point number with a NaN value then (foo != foo) and the code could go into the else block.



#3 ysg   Members   -  Reputation: 192

Like
0Likes
Like

Posted 12 March 2013 - 01:25 PM

If it's a floating point number with a NaN value then (foo != foo) and the code could go into the else block.

I'm 90% certain that it was an into of some sort.  It was pretty funny and

we both were like, yeah, this will not be mentioned in polite company

ever again :) .



#4 mhagain   Crossbones+   -  Reputation: 7467

Like
8Likes
Like

Posted 12 March 2013 - 02:50 PM

Of course if it's C++ and someone has overloaded operator == then literally anything could happen.


Edited by mhagain, 12 March 2013 - 02:51 PM.

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.


#5 Bacterius   Crossbones+   -  Reputation: 8188

Like
5Likes
Like

Posted 13 March 2013 - 01:52 AM

Of course, one could have written #define foo rand() and #define bar time(0) to be particularly treacherous. Then it would make sense. Sort of.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#6 Buster2000   Members   -  Reputation: 1453

Like
1Likes
Like

Posted 14 March 2013 - 02:58 AM

Couldn't foo and bar also be declared volotile?
 



#7 Tournicoti   Prime Members   -  Reputation: 682

Like
0Likes
Like

Posted 14 March 2013 - 05:45 AM

when x is a floating point number, if (x!=x) permits to check if x is NaN. This is terribly ugly .... but that's it wacko.png


Edited by Tournicoti, 14 March 2013 - 05:46 AM.


#8 Hodgman   Moderators   -  Reputation: 27892

Like
5Likes
Like

Posted 14 March 2013 - 06:18 AM

Couldn't foo and bar also be declared volotile?
 

Yeah, without volatile foo==foo compiles to pseudo-asm like:

int reg0 = read(&foo);
bool reg1 = compare( reg0, reg0 );

But with volatile, it would compile to something like:

int reg0 = read(&foo);
int reg1 = read(&foo);
bool reg2 = compare( reg0, reg1 );

So if the memory at &foo is constantly changing, the comparison could possibly be false.

However, that kind of code should probably never be written. Generally if your code contains volatile, then you have a bug tongue.png 

About the only place it's valid to see that keyword used, would be inside the implementation of std::atomic.



#9 ysg   Members   -  Reputation: 192

Like
1Likes
Like

Posted 14 March 2013 - 07:54 AM

Couldn't foo and bar also be declared volotile?
 

I don't think I've ever used volatile in my entire coding career.







PARTNERS