Can't get to my project to test this at the moment, but is it permissible to use bitSet and bitClear on bool variables, obviously specifying bit 0, instead of using assignments to true and false.
In my mind it is far more clear what you are doing, as in this example ....
if(eeData.cal_max != GUI.cal_max)
{
eeData.cal_max = GUI.cal_max;
bitSet(update_flag, 0);
}
TIA
Having given this more thought, I realise that bitSet() and bitClear() will be a read-modify-write operation, whereas assignments will just be a single write, making the code execution faster - is this a fair interpretation ?
A lot is allowed in the C and C++ language, but the goal should be a readable source code that shows what it is doing.
So please don't use bitSet() and bitClear() on a bool variable.
When you go beyond the normal paths, then you might expect to step into some thorny plants. Suppose the variable is 0b00000011 and you clear bit 0, then it is still not zero.
They are macros and defined in Arduino.h:
#define bitRead(value, bit) (((value) >> (bit)) & 0x01)
#define bitSet(value, bit) ((value) |= (1UL << (bit)))
#define bitClear(value, bit) ((value) &= ~(1UL << (bit)))
#define bitToggle(value, bit) ((value) ^= (1UL << (bit)))
#define bitWrite(value, bit, bitvalue) ((bitvalue) ? bitSet(value, bit) : bitClear(value, bit))
if update_flag is a bool you should use true or false in C++ as it's a type on its own.
yes your interpretation is correct, but the reason we do an assignment is more likely that it's much easier to read and understand than a bitset 
U will loose readability of the code continuing that way but if you have more than 5 bools u have to deal with then i would go with bit manipulations. Instead of dedicating 5bytes u will use 1 byte. I did that type of design in few projects i was assigned and nobody complaints.
Not to me. From my naive perspective, a bool or boolean, whatever they are called, is a type of variable.
The implementation of which is neither available to me nor of any concern.
Bit operations on boolean values makes no sense. And has been pointed out will be fraught and compromise portability.
I am an old fashioned 0 is false, everything else is true kinda person, and I haven't much dealt with variables smaller than a byte.
You might guess that I don't have much use for the new kind of true/false thing, though I do appreciate how it is intended to make getting programs corrrct or being alerted to the fact that they are not.
$0.02.
a7
I suppose using declared "true" and "false" would prevent someone typing a O (capital o) instead of a 0 (zero).
In my previous employ as a PLC systems engineer, and latterly as a PLC systems trainer, I used to see that happening a lot. I always favoured creating tags called "true" and "false", and either hard-coding them to 1 and 0, or declaring them as constants when that facility became available.
But everyone is right, assignment is better, and clearer, than bitSet and bitClear - lesson learnt, thanks people for clarifying responses
If data type is byte/int, then 0 is defined as LOW (1 is defined as HIGH); as a result, the possibility of typing O for 0 is indeed removed.
This is the opposite LOW is defined as 0
Right.
The codes would be:
#define LOW 0
#define HIGH 1
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.