Zero-choice alternative
-
TommyTomToms wrote:
DoesJessicaAlbaLoveMe != null && DoesJessicaAlbaLoveMe!= null
It is quite dangerous: if
uncertainis volatile, it may change in the meantime. Indeed, if it's not on paper, such behavior might even be expected.Greetings - Gajatko Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
Not totally sure about that without checking, but: Isn't an
ifstatement atomic, at least such a simple one? I.E.: Isuncertainallowed to change at all between the two boolean checks, may it bevolatileor not?www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software. -
If action is volatile, it would be possible for the second test to succeed even if the first fails. Indeed, if it's a memory-mapped mapped register, such behavior might even be expected.
That's true. But in that case it has to be made explicit in the code, either by using comments or a critical section or whatever may be appropriate. Otherwise it would indeed be a very severe coding horror (since it could cause an error that would be very hard to find...) X| .
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software. -
Not totally sure about that without checking, but: Isn't an
ifstatement atomic, at least such a simple one? I.E.: Isuncertainallowed to change at all between the two boolean checks, may it bevolatileor not?www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.uncertain = uncertian
I'm affraid that Jessica could change a volatile value of the
uncertianeven during the '=' symbol.Greetings - Gajatko Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
-
Not totally sure about that without checking, but: Isn't an
ifstatement atomic, at least such a simple one? I.E.: Isuncertainallowed to change at all between the two boolean checks, may it bevolatileor not?www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.If "foo" is volatile, the statement "if (foo == foo) bar();" must read the value of foo exactly twice and compare the two values read. If "foo" happens to be an address in normal RAM, the two reads would be most likely read the same data unless an interrupt or task switch happened to occur between them (not terribly likely). Not everything in a processor-based system is RAM, however. When a typical flash memory chip is performing a write cycle, consecutive read operations are guaranteed to return different data. If the generated code for the above 'if' statement didn't read 'foo' twice, the 'if' test would succeed even while the flash was still being written.
-
uncertain = uncertian
I'm affraid that Jessica could change a volatile value of the
uncertianeven during the '=' symbol.Greetings - Gajatko Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
So there's absolutely nothing you can do - this code IS dangerous and stays dangerous :). -- Or is it Jessica who is dangerous... ;)
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software. -
If "foo" is volatile, the statement "if (foo == foo) bar();" must read the value of foo exactly twice and compare the two values read. If "foo" happens to be an address in normal RAM, the two reads would be most likely read the same data unless an interrupt or task switch happened to occur between them (not terribly likely). Not everything in a processor-based system is RAM, however. When a typical flash memory chip is performing a write cycle, consecutive read operations are guaranteed to return different data. If the generated code for the above 'if' statement didn't read 'foo' twice, the 'if' test would succeed even while the flash was still being written.
Thanks for that - wasn't totally sure about it from the top of my head...
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software. -
Not totally sure about that without checking, but: Isn't an
ifstatement atomic, at least such a simple one? I.E.: Isuncertainallowed to change at all between the two boolean checks, may it bevolatileor not?www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.No, an if statement is not guaranteed to be atomic as it can be decomposed into multiple binary instructions, and a task switch can occur between any of those instructions unless the compiler designates the entire sequence as a critical section.
-
I've seriously used code like that to check for NaN.
Wouldn't float.IsNaN(x) be a more readable way to achieve that?
-
More like a second chance. Yesterday I somehow wound up writing
if ( x != x )..., I enjoyed the warning I got: warning CS1718: Comparison made to same variable; did you mean to compare something else? -
If action is volatile, it would be possible for the second test to succeed even if the first fails. Indeed, if it's a memory-mapped mapped register, such behavior might even be expected.
Reminds me of that little DOS / Win console classic to wait for a keystroke:
if (!getch()) getch();:cool: yes, this is the right way to do it -
Wouldn't float.IsNaN(x) be a more readable way to achieve that?
Only decimal numbers have NaN as static class member (at least ni C#), natural numbers like int or short don't have it. Though if something is NaN, you would get an error the moment it's assigned to a natural number variable.
-
If "foo" is volatile, the statement "if (foo == foo) bar();" must read the value of foo exactly twice and compare the two values read. If "foo" happens to be an address in normal RAM, the two reads would be most likely read the same data unless an interrupt or task switch happened to occur between them (not terribly likely). Not everything in a processor-based system is RAM, however. When a typical flash memory chip is performing a write cycle, consecutive read operations are guaranteed to return different data. If the generated code for the above 'if' statement didn't read 'foo' twice, the 'if' test would succeed even while the flash was still being written.
-
hey, if would b gr8 if u could explain wat u mean by variable being volatile
Ravie Busie Coding is my birth-right and bugs are part of feature my code has!
hey, if would b gr8 if u could explain wat u mean by variable being volatile This is not a place for programming questions, but in this context, a 'volatile' variable is one that is marked with the 'volatile' keyword. If a variable is declared volatile, expressions involving that variable may not be optimized. If 'foo' were not volatile, the code (assume foo, bar1, bar2, and bar3 are of type int):
foo = bar1;
bar2 = foo*25;
bar3 = foo*25;
foo = 8;could be safely replaced with:
bar3 = bar2 = bar1 * 25;
foo = 8;and indeed some compilers would make such a replacement. If 'foo' were volatile, however, all four of the original statements would have to be performed as-is, in sequence.