Do you not understand booleans?
-
This stuff drives me up the wall!!!
bool is_queue_empty(void)
{
if (queue_length==0)
{
return true;
}
else
{
return false;
}
}Or this:
bool counter_zero = counter==0 ? true : false;
Or this:
if (isUDPSetup()==true)
{
if ((forceSend==false))
{
...
}
}(Variable names have been changed to protect the guilty) Or this *New one*:
void setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
} -
This stuff drives me up the wall!!!
bool is_queue_empty(void)
{
if (queue_length==0)
{
return true;
}
else
{
return false;
}
}Or this:
bool counter_zero = counter==0 ? true : false;
Or this:
if (isUDPSetup()==true)
{
if ((forceSend==false))
{
...
}
}(Variable names have been changed to protect the guilty) Or this *New one*:
void setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
}You are a lucky man if that's all that makes your life miserable. Some of this is awkward, especially the second example, but where exactly is the horrible part? What damage is done? Does it not work or are there possible side effects? Does it lead to worse code being generated by the compiler? I think the first two just show a clumsy coding style, but no real harm comes from it. Except, of course, curling up your toenails when you have to read it. Usually I do the last one myself. It is at least the same way you compare any other variable (if (x == 0), so why not if (flag == true)?) and I prefer to make it absolutely clear what I want to accomplish. The compiled code remains absolutely the same, no matter how you write it. That's why I see the last one more as a matter of preferences, but not as anything important.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
You are a lucky man if that's all that makes your life miserable. Some of this is awkward, especially the second example, but where exactly is the horrible part? What damage is done? Does it not work or are there possible side effects? Does it lead to worse code being generated by the compiler? I think the first two just show a clumsy coding style, but no real harm comes from it. Except, of course, curling up your toenails when you have to read it. Usually I do the last one myself. It is at least the same way you compare any other variable (if (x == 0), so why not if (flag == true)?) and I prefer to make it absolutely clear what I want to accomplish. The compiled code remains absolutely the same, no matter how you write it. That's why I see the last one more as a matter of preferences, but not as anything important.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
You are a lucky man if that's all that makes your life miserable. Some of this is awkward, especially the second example, but where exactly is the horrible part? What damage is done? Does it not work or are there possible side effects? Does it lead to worse code being generated by the compiler? I think the first two just show a clumsy coding style, but no real harm comes from it. Except, of course, curling up your toenails when you have to read it. Usually I do the last one myself. It is at least the same way you compare any other variable (if (x == 0), so why not if (flag == true)?) and I prefer to make it absolutely clear what I want to accomplish. The compiled code remains absolutely the same, no matter how you write it. That's why I see the last one more as a matter of preferences, but not as anything important.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.The harm comes entirely from maintainance, more code == more bugs or at least harder to spot them. I apreciate your style preference on the last one, and the last thing I want is to start a style argument, but I am curious, would you also do this if you had two flags?:
if((flag1==true) && (flag2==true))
{
...
}Because this guy does, and they get longer and longer because of all the ==true and ==falses, makes simple boolean expressions look very complicated.
-
The harm comes entirely from maintainance, more code == more bugs or at least harder to spot them. I apreciate your style preference on the last one, and the last thing I want is to start a style argument, but I am curious, would you also do this if you had two flags?:
if((flag1==true) && (flag2==true))
{
...
}Because this guy does, and they get longer and longer because of all the ==true and ==falses, makes simple boolean expressions look very complicated.
Yes, I suppose this simply comes from the old C++ days where there was no boolean type. To avoid side effects or compiler specific behavior, I always explicitly specified what I was testing. But I would write it like this:
if((flag1 == true) &&
(flag2 == true) &&
(flag3 == true))
{
...
}Usually it does not look so uniform. If I really had so many different flags, I would think about using a flag word and testing all flags in one go.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
Yes, I suppose this simply comes from the old C++ days where there was no boolean type. To avoid side effects or compiler specific behavior, I always explicitly specified what I was testing. But I would write it like this:
if((flag1 == true) &&
(flag2 == true) &&
(flag3 == true))
{
...
}Usually it does not look so uniform. If I really had so many different flags, I would think about using a flag word and testing all flags in one go.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.Well this kind of code can be even more dangerous in C where you have #defined your true and false constants (dont' know if it's same in C++). Now you can get the situation where potentially neither section 1 or 2 runs:
if(a==true)
{
//1
}if(a==false)
{
//2
}At least if you don't use the constants, it behaves as a boolean, here either section 1 or 2 is guaranteed to run.
if(a)
{
//1
}if(!a)
{
//2
} -
Well this kind of code can be even more dangerous in C where you have #defined your true and false constants (dont' know if it's same in C++). Now you can get the situation where potentially neither section 1 or 2 runs:
if(a==true)
{
//1
}if(a==false)
{
//2
}At least if you don't use the constants, it behaves as a boolean, here either section 1 or 2 is guaranteed to run.
if(a)
{
//1
}if(!a)
{
//2
}Fine. Now what if a is a (signed) integer and has a negative value? Or what if a is a pointer which is currently NULL? Without having defined any value for TRUE or FALSE and without knowing how NULL was defined somewhere deep in the libraries, how do you now know which code will be executed and which not? Even if NULL is usually defined as 0x00, you cannot expect this to be true for every compiler. And what can happen if you use another compiler?
int* a = NULL;
int b = -42;if(a)
{
// We should not need to know how NULL is defined and therefore can never know wether
// or not this code block will ever be entered
}if(a == NULL)
{
// Now we explicitly compared with NULL and it is clear when this code will be executed
}if(b)
{
// Negative values are undefined and it is up to the compiler wether a negative value is
// seen as 'true' or as 'false'
}if(b < 0)
{
// Explicitly testing the variable again removes all uncertainties
}And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
Fine. Now what if a is a (signed) integer and has a negative value? Or what if a is a pointer which is currently NULL? Without having defined any value for TRUE or FALSE and without knowing how NULL was defined somewhere deep in the libraries, how do you now know which code will be executed and which not? Even if NULL is usually defined as 0x00, you cannot expect this to be true for every compiler. And what can happen if you use another compiler?
int* a = NULL;
int b = -42;if(a)
{
// We should not need to know how NULL is defined and therefore can never know wether
// or not this code block will ever be entered
}if(a == NULL)
{
// Now we explicitly compared with NULL and it is clear when this code will be executed
}if(b)
{
// Negative values are undefined and it is up to the compiler wether a negative value is
// seen as 'true' or as 'false'
}if(b < 0)
{
// Explicitly testing the variable again removes all uncertainties
}And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.I am with you that if it's an integer or pointer do the code like you have described, it's fine code, I do prefer to do it this way. But you still arn't using defines for true and false, which is my original beef. However any compiler that doesn't define zero as false and non-zero as true for boolean expressions is not a standard C compiler.
-
I am with you that if it's an integer or pointer do the code like you have described, it's fine code, I do prefer to do it this way. But you still arn't using defines for true and false, which is my original beef. However any compiler that doesn't define zero as false and non-zero as true for boolean expressions is not a standard C compiler.
The simple answer: I would, for example, use the Win32 type BOOL. I can safely compare any variable of the type BOOL to the definitions of TRUE or FALSE and that is what I would do. Trying to compare any variable of another type with TRUE or FALSE would be asking for trouble. Also, I would not use other types to express boolean values, even if C/C++ allows this, so that there is never any need to compare them to TRUE or FALSE
BOOL b = TRUE;
int i = 1;if(i == TRUE)
{
// TRUE may be defined in numerous ways, so this is likely not to work
// I would simply not use an int (or other types) to express boolean values.
}if(b)
{
// It would be logical to assume that this works, but who knows how TRUE has
// really been defined. In any case, we should not have to know and that
// is why I avoid it.
}if(b == 1)
{
// TRUE (the value of b) may be defined in numerous ways, so this is likely not to work
}if(b == i)
{
// Very bad. Even if the definition of BOOL is based on int, it's unsafe to assume that this is so. And again
// we should not have to care about how TRUE or FALSE are defined.
}if(b == TRUE)
{
// No problem here. Explicitly comparing a BOOL variable with TRUE or FALSE seems to be the only safe way.
}Coming back to managed languages where a boolean type exists: Here no other type can be used to express boolean values, so explicitely comparing to true or false is not needed. I guess it's simply a habit I have carried over without thinking much about it.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
I am with you that if it's an integer or pointer do the code like you have described, it's fine code, I do prefer to do it this way. But you still arn't using defines for true and false, which is my original beef. However any compiler that doesn't define zero as false and non-zero as true for boolean expressions is not a standard C compiler.
alanevans wrote:
define zero as false
What size of zero? :-D Even defining it as zero may be problematic down the line. One place I worked (which had to compile its code for 16-bit DOS, 32-bit Windows, and 64-bit OpenVMS used:
# define true (0==0)And were therefore protected against issues of size, or whether zero was true or false, or even if some future compiler has an actual boolean type. That, in my opinion, is the only way to go. -
You are a lucky man if that's all that makes your life miserable. Some of this is awkward, especially the second example, but where exactly is the horrible part? What damage is done? Does it not work or are there possible side effects? Does it lead to worse code being generated by the compiler? I think the first two just show a clumsy coding style, but no real harm comes from it. Except, of course, curling up your toenails when you have to read it. Usually I do the last one myself. It is at least the same way you compare any other variable (if (x == 0), so why not if (flag == true)?) and I prefer to make it absolutely clear what I want to accomplish. The compiled code remains absolutely the same, no matter how you write it. That's why I see the last one more as a matter of preferences, but not as anything important.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
why not if (flag == true)?
Indeed, I prefer that when writing in C. One thing that drives me nuts with C is reading things like:
char* s = ...
if ( s ) ...
:mad:
-
CDP1802 wrote:
why not if (flag == true)?
Indeed, I prefer that when writing in C. One thing that drives me nuts with C is reading things like:
char* s = ...
if ( s ) ...
:mad:
Me too, but then there are the 'noobs' who just know languages like C# or Java and make up smart coding rules which only work as long as they don't ever have to leave their comfortable little world. At times I still have to use some old school methods and have no choice but to ditch object orientation or *gasp* use branching instructions (that's something like GOTO). Our 'modern' friends would not get very far with their 'must do this' and 'don't do that' rules.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
alanevans wrote:
define zero as false
What size of zero? :-D Even defining it as zero may be problematic down the line. One place I worked (which had to compile its code for 16-bit DOS, 32-bit Windows, and 64-bit OpenVMS used:
# define true (0==0)And were therefore protected against issues of size, or whether zero was true or false, or even if some future compiler has an actual boolean type. That, in my opinion, is the only way to go.Yep. I used to do that myself.
#define true (1==1)
#define false (1==0)If your language does not define values, it's the only sensible way to do it.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Me too, but then there are the 'noobs' who just know languages like C# or Java and make up smart coding rules which only work as long as they don't ever have to leave their comfortable little world. At times I still have to use some old school methods and have no choice but to ditch object orientation or *gasp* use branching instructions (that's something like GOTO). Our 'modern' friends would not get very far with their 'must do this' and 'don't do that' rules.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.OP used C#. It might possibly look like it could be an other language, but the pre tag has lang="cs". Comparing bools with constants is nonsensical in C#. Comparing bools with constants in x86 assembly makes even less sense and takes special effort just to do it wrong.
-
OP used C#. It might possibly look like it could be an other language, but the pre tag has lang="cs". Comparing bools with constants is nonsensical in C#. Comparing bools with constants in x86 assembly makes even less sense and takes special effort just to do it wrong.
harold aptroot wrote:
Comparing bools with constants is nonsensical in C#.
And it's in no way harmful. But it is consistent with other comparisons.
harold aptroot wrote:
Comparing bools with constants in x86 assembly makes even less sense and takes special effort just to do it wrong.
That I see differently. Defining a boolean type and declaring adequate constants to use with it eliminates most of the problems. Of course only if you use your boolean type for boolean values and nothing else. Unfortunately there is no way to limit your boolean type to just 'true' and 'false' and there is also no mechanism to enforce the use of your boolean type. As always, this is the point where only discipline helps. And let's not forget this little detail:
int x = -5;
if(x)
{
// will this block be executed?
}
else
{
// or this one?
}And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
harold aptroot wrote:
Comparing bools with constants is nonsensical in C#.
And it's in no way harmful. But it is consistent with other comparisons.
harold aptroot wrote:
Comparing bools with constants in x86 assembly makes even less sense and takes special effort just to do it wrong.
That I see differently. Defining a boolean type and declaring adequate constants to use with it eliminates most of the problems. Of course only if you use your boolean type for boolean values and nothing else. Unfortunately there is no way to limit your boolean type to just 'true' and 'false' and there is also no mechanism to enforce the use of your boolean type. As always, this is the point where only discipline helps. And let's not forget this little detail:
int x = -5;
if(x)
{
// will this block be executed?
}
else
{
// or this one?
}And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.Yes but that's C, not x86 assembly. Suppose you have a nice boolean in the flags, say the Z flag, and you want to compare it with a constant..
mov eax,0
setz al
cmp eax,someconstantOk maybe that's not the best possible way to do it, but it doesn't really matter. Whatever you do, it will be completely useless and you might as well have used the flag directly. And actually, it is harmful. It will take yet an other second to mentally decode what the heck is going on.
-
alanevans wrote:
define zero as false
What size of zero? :-D Even defining it as zero may be problematic down the line. One place I worked (which had to compile its code for 16-bit DOS, 32-bit Windows, and 64-bit OpenVMS used:
# define true (0==0)And were therefore protected against issues of size, or whether zero was true or false, or even if some future compiler has an actual boolean type. That, in my opinion, is the only way to go.Surely a zero is the same size whatever the width of numbers? For negative values you have to be careful but zero and small positive integers should work for everywhere. That's quite a neat way of defining true, except that it presumably results in an extra comparison taking place in every test where you use it.
-
CDP1802 wrote:
why not if (flag == true)?
Indeed, I prefer that when writing in C. One thing that drives me nuts with C is reading things like:
char* s = ...
if ( s ) ...
:mad:
And yet that style of testing for non-null is the standard in, for example, JavaScript. (Personally I have no problem with it in C either, for pointer or unsigned types ... with signed values it's bad because as pointed out someone could potentially switch negative values' interpretation out from under you.) When comparing against something which is (semantically or definitively, depending on your language) a boolean, though, there's absolutely no reason to make the reader parse more text before he can understand your statement. Adding the ' == true' provides zero clarification value, as anyone who vaguely knows the language knows that if tests check for a true value. In your example here, adding the ' != NULL' does provide a little clarification, so it's pretty much a value-neutral stylistic choice to add it or not. (Someone might suggest that NULL could evaluate to true, but anyone who makes that #define is far more culpable for any confusion than the person who writes the check you put here, and in any professional context that won't be the case.)
-
Yes but that's C, not x86 assembly. Suppose you have a nice boolean in the flags, say the Z flag, and you want to compare it with a constant..
mov eax,0
setz al
cmp eax,someconstantOk maybe that's not the best possible way to do it, but it doesn't really matter. Whatever you do, it will be completely useless and you might as well have used the flag directly. And actually, it is harmful. It will take yet an other second to mentally decode what the heck is going on.
harold aptroot wrote:
Yes but that's C, not x86 assembly.
Sorry, there I was in the wrong show. It's friday afternoon :)
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
Surely a zero is the same size whatever the width of numbers? For negative values you have to be careful but zero and small positive integers should work for everywhere. That's quite a neat way of defining true, except that it presumably results in an extra comparison taking place in every test where you use it.
