bit-fields vs. egyptian integer flags?

[mij...@yahoo.com]

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]

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.
--
Flash Gordon

[nick_keigh...@hotmail.com]

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

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

On 19 Feb, 04:42, mijo...@yahoo.com wrote:
>
> 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

--
Nick Keighley

My god it's full of stars!
Dave Bowman, on seeing HAL's source code

[nick_keigh...@hotmail.com]

On 19 Feb, 10:51, nick_keighley_nos...@hotmail.com wrote:

> 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]

mij...@yahoo.com writes:

> 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});

--
Ben.

[Hallvard B Furuseth]

Ben Bacarisse writes:
>mij...@yahoo.com writes:
>> 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.

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.

> 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

[mij...@yahoo.com]

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

[Richard Harter]

On Wed, 18 Feb 2009 20:42:42 -0800 (PST), mij...@yahoo.com
wrote:

As you see from other responses, no it is not. There is a third
alternative that you didn't mention, using enumerated type, again
with the flag being an unsigned int. Here is a fragment example
from some code:

enum gfl_flags {
gfl_clean = 0x1, gfl_eofok = 0x2, gfl_cut = 0x4,
gfl_trunc = 0x8, gfl_omit = 0x10, gfl_exit = 0x20,
gfl_log = 0x40, gfl_nomax = 0x80
};

I will leave it to wiser heads as to decide which is better, but
using an enum is more compact than a mass of defines.

Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Nate Eldredge]

nick_keigh...@hotmail.com writes:

> Subject: "bit-fields vs. egyptian integer flags?"
>
> and what, pray tell, is an Egyptian Integer? Arabic numerals?
>
>
> On 19 Feb, 04:42, mijo...@yahoo.com wrote:
>>
>> 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.

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.

[nick_keigh...@hotmail.com]

On 19 Feb, 16:31, Nate Eldredge <n...@vulcan.lan> wrote:

> nick_keighley_nos...@hotmail.com writes:
> > Subject: "bit-fields vs. egyptian integer flags?"

> > On 19 Feb, 04:42, mijo...@yahoo.com wrote:

> >> 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.
>
> 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