Does this type need to exist in the year 2018 or can we use a more standardized bool type?
Fwiw, please consider that for bitfields of one bit (e.g. bool changed: 1;) the values will be 0 and -1 due to bool being a signed char. If we ensure consistency on usage it shouldn't be an issue.
Okay, I feel less concerned now. I assumed the treatment is the same as it was to a signed char.
However, upon further testing, the bitfield bool value was converted from the stored 1 to 1 (or: true), as opposed to -1, (which I expected it to be).
Looks like C99 adds an implicit conversion for bool types.
Couldn't find an exact mention of this in neither stdbool.h nor GNU99 docs, but some text implies such behavior.
In any case, I guess i'm on board :)
btw - check on arm. chars are unsigned by default there for example - different architectures may be different... but for existing efl - no. shouldn't change. efl 2.0 - anything goes. :)
Well, its basically a tradeoff, you *maybe* safe memory, while wasting performance, (the assembly created for that purpose is quite horrible, which is needed, but still not nice...)
For getting the same things you could also just have constants that you or / and onto a data word in you struct.
Which would result in clear or and and instructions in the assembly, without the need of shifting a value to the possition so it can be OR'ed into the memory segment of the struct.
And result in a more compact definition.
I'd prefer to use unsigned x : 1; instead of bool x : 1;.
I personally am not a fan of bitfields, because of their undefined and implementation-defined behaviors and the fact they are not always well-handled by compilers (e.g. Diab).
i've never found a compiler that doesn't handle them that would be used to compile my code (e.g. for linux and other posix systems) - so never ran into that... and i have never noted undefined behavior if i just use the bitfield as a boolean like if (x->field) a(); else b();. it's rare i use more than 1 but (but have done so to pack stuff more to save space).
as for instructions ... it depends on architecture. i remember the 68k having a btst instruction to test a single bit in a register which would be used as the cmp instruction to base the next jsr off, so it would be no extra code there. x86 has the tst instruction to test a single bit being on, and arm also has a tst instruction too that updates condition flags based on bits being set in the logical and. otherwise it would depend. like the above if's could do something like (in pseudo-assembly):
andbi #4, addr0, reg0; //and immediate byte value with 4 (3rd lowest bit) and store in reg0 jsr true_path; // and will set the status register based on any bits being true during the and
or if status reg isn't set:
andbi #4, addr0, reg0; //and immediate byte value with 4 (3rd lowest bit) and store in reg0 cmpbi #i, reg0; // compare register with immediate value 4 (is the bit on) jsr true_path; // and will set the status register based on any bits being true during the and
without the bitfield you could just cmpbi directly on the value compare to 1... every instruction set i can remember seeing has some kind of immediate constant value operations for add, sub, mov etc. etc. so the compiler can nicely know the exact byte location and stick to just using small 8bit immediates... but yeah - without bit test instruction it's and extra instruction, but i suspect that the cost of that is dwarfed by the savings in cache misses. have som data structs in efl that have like 20 or so bit fields... that'd eat up 20 bytes of space without bitfields, and with only uses 4 bytes. a cache miss is 100-300 cycles these days. i am sure extending data structs to be fatter is going to cause some misses more and thus i'd say in the end makes up for the extra instruction :)