1bit Booleans? Just checking...

Forum 2005-2010 (read only) General Frequently-Asked Questions
1

Sorry to bother with, again, stupid things... but, I wonder, why the compiler doesn't manage a way to make boolean variables use 1 bit? Just wondering, like, it could have a list of 8 bit page variables and have 8 boolean variables on each. Anyway, I'm doing this manually, but I hope not in a stupid way that will make people laugh "HA HA!" when they see... :cry: :-[

// Multi Boolean Variable //
unsigned int multiBoolean1 = 0;
#define doLCDupdate 0
#define nextPatternReady 1
#define patternBufferN 2

void mB(uint8_t pos, uint8_t value)
{
  bitWrite(multiBoolean1,pos,value);
}

uint8_t mB(uint8_t pos)
{
  return bitRead(multiBoolean1,pos);
}
2

C doesn't actually have a "boolean" type; it's usually just a synonym for a convenient other native type (int or char)
Single bit variables tend to be expensive to access, although various "extended" features have sometimes allow boolean return values to be communicated via a CPU status bit rather than a full register.

3

Why not use standard C bitfields...? You're not really saving much honestly, but I think they are cleaner than manually shifting bits around yourself.

typedef struct myPrefsStruct
{
uint8_t doLCDupdate: 1
uint8_t nextPatternReady: 1
uint8_t patternBufferN: 1
};

the number after the colon indicates the number of bits to use for each field. So then you declare a variable of your shiny new type

myPrefsStruct myPrefs;

and then are free to access each field as a normal structure field. Eg:

myPrefs.doLCDupdate = true;

Cheers,

4

Thanks, but will this actually use only one bit of memory for each variable?

Wk

5

With the code above I just go like this:

mB(doLCDupdate,1);

if (mB(doLCDupdate))
{
     // Do Something
     mB(doLCDupdate,0);
}

So its very simple too, and it saves a lot of memory from the tests I have done.

Wk

6

Using bitfields will save a lot of memory (depending on how much booleans you need) but it uses extra code to strip the "bit out the byte". This is typical a memory against speed tradeoff, and it depends on the application.

Rethinking and redesigning your application - create a 2.0 version - leads to more gain that locally optimizing.

7

Right now there's no speed problems, as the only time-critical part of the code is very short: the midi clock.

All the heavy stuff is done in the loop and is not time-critical.

What I love about timers is that it actually creates a second thread, short, but still great for usage.

Wk