How to test equality
-
Actually, I would use
bitVar = ((byteVar & 0x40) == 0x40);. Using the!= 0or in your case the!!style will work if you are comparing a single bit, but it will break if you are comparing multiple bits:bitVar = ((byteVar & 0x41) == 0x41);is not the same asbitVar = ((byteVar & 0x41) != 0);.
You may be right I may be crazy -- Billy Joel -- Within you lies the power for good - Use it!
PJ Arends wrote:
Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
If I am testing multiple bits, I will either explicitly test for being unequal to zero, or being equal to a particular number (depending upon whether the requirement is that at least one bit be set, or that all bits be set). I do not like the syntax you seem to favor, since its normal semantic meaning requires that the same constant appear on both halves of the comparison operator; if the two halves get edited out of sync, the code will break.
-
PJ Arends wrote:
Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
If I am testing multiple bits, I will either explicitly test for being unequal to zero, or being equal to a particular number (depending upon whether the requirement is that at least one bit be set, or that all bits be set). I do not like the syntax you seem to favor, since its normal semantic meaning requires that the same constant appear on both halves of the comparison operator; if the two halves get edited out of sync, the code will break.
I agree. Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting. :)
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
-
supercat9 wrote:
Anything wrong with that?
Everything! It is not an operator in the sense of being part of the language. It is a clever trick that you may understand, but is likely to confuse someone who later has the job of maintaining the code. In my experience the more simple and standard the code is the better. Whether you write
bitVar = !!(byteVar & 0x40);orbitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.Richard MacCutchan wrote:
In my experience the more simple and standard the code is the better. Whether you write bitVar = !!(byteVar & 0x40); or bitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.
I use the more verbose syntax when testing more than one bit, to make explicit whether I am checking for any bit being set, or all bits being set. Whether or not anyone else uses the same convention, I find that at least in my own code it's nice to be able to distinguish at a glance between single-bit tests and multi-bit tests.
-
I agree. Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting. :)
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
Luc Pattyn wrote:
Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
I like named constants too, but many of the same issues remain. If I have a test: if ((somevariable & SOMEIDENTIFIER) == SOMEIDENTIFIER) I have to worry about whether the two "SOMEIDENTIFIER"s are the same. If the identifiers are the same and the value gets changed (but remains a power of two) things will be fine, but if the code is copied/pasted and then modified to use a different identifier, an imperfect patch job could cause all sorts of problems.
-
Luc Pattyn wrote:
Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
I like named constants too, but many of the same issues remain. If I have a test: if ((somevariable & SOMEIDENTIFIER) == SOMEIDENTIFIER) I have to worry about whether the two "SOMEIDENTIFIER"s are the same. If the identifiers are the same and the value gets changed (but remains a power of two) things will be fine, but if the code is copied/pasted and then modified to use a different identifier, an imperfect patch job could cause all sorts of problems.
I agree once more. If SOMEIDENTIFIER has more than one bit set, it all depends on the intent of the snippet; a switch might even be in order then. :)
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
-
I agree once more. If SOMEIDENTIFIER has more than one bit set, it all depends on the intent of the snippet; a switch might even be in order then. :)
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
I guess my main point is that I view testing for a single bit as being a different operation from testing a multi-bit expression numerically (a judgment colored perhaps by the existence of instructions on my favorite microcontrollers to perform such tests). Using an expressions like "!!(expr & BITMASK)" for the cases where BITMASK is a single bit makes clear that the code is supposed to look at a single bit, as opposed to numerically masking the expression and examining the result. The compiler will recognize the single-bit mask and generate code to exploit the bit-test instructions regardless of how the source code is written, but I like having a different way of expressing single-bit tests from multi-bit ones. BTW, I sometimes use 'case' structures for the multi-bit case, though if all four cases of two bit flags are populated, I'll often use an if/else-if tree, depending on what sort of speed is required.
-
My favorite coding horror isn't over the top, nor does it leave the system more vulnurable than it began. But how can I honestly trust anyone who does the following:
// getting some user session settings
if(!!isLocked)
{
// abort the login and show an error message.
}
else
{
// login the user.
}This wasn't a mistake on their part either. They used this kind of test in more than 50 places...
This could have resulted from a quick conversion of Assert() statements. The assert is a positive statement that explodes if not true. To covert them to execute a non-lethal action the quickest and perhaps safest approach is to just change to an if() throwing a NOT in front of the expreseion. New error handling code follows. ...not advocating this, just offering an explanation.
-
My favorite coding horror isn't over the top, nor does it leave the system more vulnurable than it began. But how can I honestly trust anyone who does the following:
// getting some user session settings
if(!!isLocked)
{
// abort the login and show an error message.
}
else
{
// login the user.
}This wasn't a mistake on their part either. They used this kind of test in more than 50 places...
That construct is often used to avoid warning C4800 [^]
-
c#5 will be shipping with this features ! => CertainlyNot() !! => DefinitelyNot() !!! => ReallyTrustMeItIsNot() :laugh: PS: still lying on the floor...
(yes|no|maybe)*
-
nathan.northcutt@gmail.com wrote:
if(!!isLocked)I wonder if it means
DefinitelyNot()? :laugh:Definitely not! It means not not, does it not?
