Do you not understand booleans?
-
void setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
}This would be better if they returned it too. Nothing like getting back what you put into it.
bool setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
return NeedsUpdate;
}Excellent, in addition this provides a way to test that assignment succeeded and was correct. I would even suggest
bool setNeedsUpdate(bool update)
{
if ((update==true))
{
NeedsUpdate=true;
return NeedsUpdate;
}
else
{
NeedsUpdate=false;
return NeedsUpdate;
}
}so that if the code has a logic flaw, the function never returns ! ;)
-
Just ran across this in code I've been asked to maintain (no kidding):
if (((ucGlobalHeaterEnable & (1 << UC_BHOSE_HTR_ON) ) > 0) ? 1 : 0)
{
...
}Unbelievable!
Rather indigestible indeed. I couldn't resist rewriting this piece using bit fields (in my opinion a sadly underused feature in C):
struct tGlobalHeaterEnable
{
bool bHoseHtrOn: 1;// More fields here...} sGlobalHeaterStatus;
if (sGlobalHeaterEnable.bHoseHtrOn)
{
// More code here...
} -
Personally, I don't promote the C rule that implicitly turns an expression to boolean based on zeroness, whatever the type. Because even though perfectly legal it looks like a quick & dirty shorthand to spare typing a comparison; and it can overload an identifier with two meanings, that of the numerical value (or address) and that of a condition, as if the variable had two data types. What would you think of this (fiddled) snippet:
int NoRetries; // Number of sending retries
NoRetries= SendMessage();
if (NoRetries)
{
// Investigate
}as opposed to
if (NoRetries > 0)
{
// Investigate
}C was lacking a boolean type in the old days, in my opinion a design flaw. That made the aforementioned rule perfectly relevant. I prefer making the booleans explicit and highlighted. In a moderatly pedantic style, this would give us
bool Retried= NoRetries > 0;
if (Retried)
{
// Investigate
}I absolutely agree with you and consider using the a-zero-int-value-is-a-bool-false feature of C/C++ to be sloppy. Valid, but sloppy. I consider it sloppy because 0 is a meaningful (and highly useful) value for an int. However, with pointers, NULL is a meaningful value that indicates the pointer points to nothing, all other values are considered valid pointers. Using a pointer like a bool and checking if it is explicitly NULL are the same -- they are both asking if it points to anything. There is no other possible semantic interpretation. Writing code that omits an explicit comparison to NULL is also more easier to upgrade if the pointer is switched to one of the boost smart pointer classes, something we've done a fair amount of over the years. Not that the compiler doesn't catch the now-invalid comparison, but then you have to touch all that code just to get the same semantic meaning.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
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;
}I'm with you on this one! Sometimes verbosity improves readability, but there are many cases where it's just dumb. The first example is terrible:
bool is_queue_empty(void)
{
if (queue_length==0)
{
return true;
}
else
{
return false;
}
}More code & multiple exit points -- for zero benefit???!!! X| This would be better:
bool is_queue_empty(void)
{
return queue_length == 0;
}:)
-
I absolutely agree with you and consider using the a-zero-int-value-is-a-bool-false feature of C/C++ to be sloppy. Valid, but sloppy. I consider it sloppy because 0 is a meaningful (and highly useful) value for an int. However, with pointers, NULL is a meaningful value that indicates the pointer points to nothing, all other values are considered valid pointers. Using a pointer like a bool and checking if it is explicitly NULL are the same -- they are both asking if it points to anything. There is no other possible semantic interpretation. Writing code that omits an explicit comparison to NULL is also more easier to upgrade if the pointer is switched to one of the boost smart pointer classes, something we've done a fair amount of over the years. Not that the compiler doesn't catch the now-invalid comparison, but then you have to touch all that code just to get the same semantic meaning.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
Sorry, no exception even for convenience. An integer is an integer, a pointer is a pointer and a boolean is a boolean.