Bitfields

[Jon Slaughter]

I'm using bit fields to compactly represent some data I need to manage and
I've read that they are not portable. I don't understand why that is the
case? As long as I don't "indirectly" mess with the fields and I go through
the compiler and allow it to choose the appropriate way to handle them then
why shouldn't it be ok?

The whole point of me using bit fields was so that I could be somewhat
portable instead of managing the bits myself(by extracting and inserting
them into ints using the logical operators).

I understand that the compiler doesn't guarantee alignment or packing but I
feel that as long as I let the compiler deal with the fields then it should
be ok?

Also, I read that there can be a "speed" hit when using bitfields? I don't
really see how this can be true since it only involves a few logical
operators and shifts? (Maybe in specific instances where one is looping over
something that runs in a few cycles where these extra instructions could be
significant might it be a big deal but I don't see why in general)

So, if there are at times a speed issues... for example, lets say that I run
my program and it turns out by using the "bit fields" I get a speed hit...
is there any way to force the compiler to turn those "bit fields" into
standard types(such as int)

i.e.

lets say I have

struct blah
{
unsigned a : 4;
unsigned b : 1;
unsigned d : 9;
}

and I want to "increase the speed", could I tell it to "implicitly" convert
the bit fields into ints? something like

struct blah
{
unsigned a : 8;
unsigned b : 8;
unsigned d : 16;
}

or even

struct blah
{
unsigned a : 32;
unsigned b : 32;
unsigned d : 32;
}
?
Thanks

Jon

[Jon Slaughter]

oh, I'd like to mention one more thing, does C++ pack bitfields together?

I have two bitfields that are not aligned such as

struct A
{
unsigned a : 1;
}

strubt B
{
unsigned b : 1;
}
now C++ should pack them into 1 int instead of 2, will it do this?

i.e., will it treat the structures as one such as

struct C
{
unsigned a : 1;
unsigned b : 1;
} ?
(I am using visual studio.net)

The point is that I will potentially have lots of little objects in my
application that have bit fields(properties) "attached" to them and I see no
need to waste space on them all.

Lets say I have 1000 objects with 15 properties each and an overhead of
about 8 bytes per object.

so thtats 1000*(8 + 15*4) = 68000 bytes if using int(32-bit) fields while if
I pack them I'd probably save about 1/5 of that(or more).

I know 68k isn't much but I see no need to waste space any more than I have
to... maybe I am being anal about this? (and the 1000 though can be up to
10k or even more(though I doubt it would be close to 100k).

Maybe the extra computation time is not worth the savings in memory? (I
doubt my application would ever use more than 20 megs of memory but it might
be ran along side of an app that is a memory hog(and also a cpu hog).

[Sensei]

Jon Slaughter wrote:

oh, I'd like to mention one more thing, does C++ pack bitfields together?

I have two bitfields that are not aligned such as

struct A
{
unsigned a : 1;
}

strubt B
{
unsigned b : 1;
}
now C++ should pack them into 1 int instead of 2, will it do this?

i.e., will it treat the structures as one such as

struct C
{
unsigned a : 1;
unsigned b : 1;
} ?
Have you tried to do a sizeof() of the three? You'll know!
I know 68k isn't much but I see no need to waste space any more than I have
to... maybe I am being anal about this? (and the 1000 though can be up to
10k or even more(though I doubt it would be close to 100k).

Maybe the extra computation time is not worth the savings in memory? (I
doubt my application would ever use more than 20 megs of memory but it might
be ran along side of an app that is a memory hog(and also a cpu hog).

Try to use different data structures.

[msalters]

Jon Slaughter wrote:

I'm using bit fields to compactly represent some data I need to manage and
I've read that they are not portable. I don't understand why that is the
case? As long as I don't "indirectly" mess with the fields and I go through
the compiler and allow it to choose the appropriate way to handle them then
why shouldn't it be ok?
There are a few corner cases (signed 1-bit). Don't
worry about those. The other common portability mistake
is saving the structure as sizeof(struct) bytes to disk
and assuming another program can read those same bytes
back. That's a form of "indirectly messing".
The whole point of me using bit fields was so that I could be somewhat
portable instead of managing the bits myself(by extracting and inserting
them into ints using the logical operators).
Both methods are just as portable, altough bitfields could
be slightly faster.
I understand that the compiler doesn't guarantee alignment or packing but I feel that as long as I let the compiler
deal with the fields then it should be ok?
Yes.
Also, I read that there can be a "speed" hit when using bitfields? I don't
really see how this can be true since it only involves a few logical
operators and shifts? (Maybe in specific instances where one is looping over
something that runs in a few cycles where these extra instructions could be
significant might it be a big deal but I don't see why in general)
In general, writing one field in a bitfield means you need
a read-modify-write cycle. The compiler ensures you don't
actually overwrite other bits. If you've programmed the
equivalent bit ops, you'll understand this - most people
get this wrong the first time.
So, if there are at times a speed issues... for example,
lets say that I run my program and it turns out by using
the "bit fields" I get a speed hit. Is there any way to
force the compiler to turn those "bit fields" into
standard types(such as int)

i.e.

lets say I have

struct blah
{
unsigned a : 4;
unsigned b : 1;
unsigned d : 9;
}

and I want to "increase the speed", could I tell it to
"implicitly" convert the bit fields into ints?

What about simply removing the : 4 ? That would make a
an unsigned int with the "natural size". Of course, that
would mean that an instruction like ++a does something
different (doesn't wrap at 15)

HTH,
Michiel Salters