bit-fields vs. egyptian integer flags?

[mijoryx]

Does anyone have a good basis upon which to
prefer using bit-fields for true/false settings
or a big integer with macros for each power
of two?

eg.
struct {
unsigned exec: 1;
unsigned read: 1;
unsigned write: 1;
} flag;
flag.exec = 1;
if (flag.exec) {...}

vs.
unsigned flag;
#define Fexec 1
#define Fread 2
#define Fwrite 4
flag |= Fexec;
if (flag & Fexec) {...}

Is it just a matter of punctuation?

luXer-ex-troXX

 

[Flash Gordon]

Does anyone have a good basis upon which to
prefer using bit-fields for true/false settings
or a big integer with macros for each power
of two?

eg.
struct {
unsigned exec: 1;
unsigned read: 1;
unsigned write: 1;
} flag;
flag.exec = 1;
if (flag.exec) {...}

vs.
unsigned flag;
#define Fexec 1
#define Fread 2
#define Fwrite 4
flag |= Fexec;
if (flag & Fexec) {...}

Is it just a matter of punctuation?

It all depends on what you are going to do with flag. The disadvantage
of bitfields is if you are passing it to some other application on
potentially another system, since whether they start at the high or low
bit is implementation defined. If that is not a problem I think I would
prefer bit fields.

 

[Guest]

Subject: "bit-fields vs. egyptian integer flags?"

and what, pray tell, is an Egyptian Integer? Arabic numerals?

Does anyone have a good basis upon which to
prefer using bit-fields for true/false settings
or a big integer with macros for each power
of two?

yes, use an integer and macros. You can't trust bitfields
to be portable.

eg.
struct {
    unsigned exec: 1;
    unsigned read: 1;
    unsigned write: 1;} flag;

flag.exec = 1;
if (flag.exec) {...}

vs.
unsigned flag;
#define Fexec 1
#define Fread 2
#define Fwrite 4
flag |= Fexec;
if (flag & Fexec) {...}

or
#define F_EXEC 0x01
#define F_READ 0x02

which makes a difference as the numbers get larger

#define F_SNARG 0x10

Some people like:

#define F_EXEC (1 << 0)
#define F_READ (1 << 2)
#define F_SNARG (1 << 8)

but I think its a bit "clever"

You could also hide the operators

#define SET_FLAG(VAL,FLAG) (VAL) |= (FLAG)
#define FLAG_IS_SET(VAL,FLAG) (VAL) & (FLAG)

SET_FLAG (file_command, F_READ);

if (FLAG_IS_SET (file_command, F_WRITE))
do_right_stuff();

Is it just a matter of punctuation?

and portability. And the macro versions are easier to write
correctly

 

[Guest]

Subject: "bit-fields vs. egyptian integer flags?"

and what, pray tell, is an Egyptian Integer? Arabic numerals?

<snip>
<websearch>

1. a set of hieraglyphs for representing numbers. The symbol
for a coil of rope is 100 "God of infinite" is 1,000,000

2 "A positive integer N is Egyptian if it can be partitioned in the
form
N = a_1 + a_2 + ... + a_k in which a_1, a_2, ..., a_k are
positive
integers, not necessarily distinct, such that 1/a_1 + 1/a_2 + ...
+
1/a_k = 1. "

The Egyptian numbers are 1,4,9,10,11,16,17,18,20,22, and all
integers >= 24.

So which one did you mean?

 

[Ben Bacarisse]

Does anyone have a good basis upon which to
prefer using bit-fields for true/false settings
or a big integer with macros for each power
of two?

You've had some good answers, but let me add a bit more... One reason
for preferring integer constants can be that a complex set of bits has
a single value that can passed about, assigned, etc.

If you have C99, then compound literals allow you to write struct
values (and designated initialisers make it quite readable):

struct flags {
unsigned exec: 1;
unsigned read: 1;
unsigned write: 1;
};
...
set_options((struct flags){.exec = 1, .write = 1});

 

[Hallvard B Furuseth]

You've had some good answers, but let me add a bit more... One reason
for preferring integer constants can be that a complex set of bits has
a single value that can passed about, assigned, etc.

And AND/OR/XORed with one expression. You can't do that with bitfields,
even in C99.

An advantage of bitfields (and non-bitfields for that matter) is that
they may spell out more clearly what the program is doing. You want to
set some specific condition in the struct: You create a member variable
for just that condition, without mixing it up with other matters.

 

[mijoryx]

<snip>
<websearch>

1. a set of hieraglyphs for representing numbers. The symbol
   for a coil of rope is 100 "God of infinite" is 1,000,000

2 "A positive integer N is Egyptian if it can be partitioned in the
form
   N = a_1 + a_2 +  ... + a_k in which a_1, a_2, ..., a_k are
positive
   integers, not necessarily distinct, such that 1/a_1 + 1/a_2 + ...
+
   1/a_k = 1. "

    The Egyptian numbers are 1,4,9,10,11,16,17,18,20,22, and all
    integers >= 24.

So which one did you mean?  

I was refering to the use of binary decomposition
for arithmetic operations. A better term would
probably have been "egyptian-style" binary sequence.

Or perhaps the reference is too obscure. I was mostly
trying to appear clever. As with coolness, cleverness
may be inversely proportional to the effort required
for the attempt.

Did you know?
The letter 'sh' can easily be traced from hieroglyphics
to hebrew to coptic to russian? Mnemonic: shhhh! you'll
wake the flowerpot!

luXer-ex-troXX

 

[Nate Eldredge]

Subject: "bit-fields vs. egyptian integer flags?"

and what, pray tell, is an Egyptian Integer? Arabic numerals?




yes, use an integer and macros. You can't trust bitfields
to be portable.

Can you clarify in what sense you mean "portable"?

Bitfields are portable in the sense that every standard C compiler will
support them. There may be some question as to whether different
compilers will *represent* them in the same way, leading to possible
difficulties when exchanging data between programs (or programs and
libraries, or programs and hardware), but this is a matter that the
platform's ABI should deal with, and not a problem with the feature per
se. And for a program that will only be using them internally, it's not
an issue.

 

[Guest]

Can you clarify in what sense you mean "portable"?

I was assuming the OP cared about which bit went where.

Bitfields are portable in the sense that every standard C compiler will
support them.  There may be some question as to whether different
compilers will *represent* them in the same way, leading to possible
difficulties when exchanging data between programs (or programs and
libraries, or programs and hardware), but this is a matter that the
platform's ABI should deal with, and not a problem with the feature per
se.  

I don't see how it can. If the library/hardware/comms interface
say its bit-0 then it has to be bit-0 and bit fields provide
no portable way of accessing bit-0.

And for a program that will only be using them internally, it's not
an issue.

agreed, but this is the only time they are portable