tags:

views:

343

answers:

3

I have a C++ application that includes a number of structures with manually controlled bit fields, something like

#define FLAG1   0x0001  
#define FLAG2   0x0002      
#define FLAG3   0x0004      

class MyClass
{
'
'
  unsigned Flags;

  int IsFlag1Set() { return Flags & FLAG1; }
  void SetFlag1Set() { Flags |= FLAG1; }
  void ResetFlag1() { Flags &= 0xffffffff ^ FLAG1; }
'
'
};

For obvious reasons I'd like to change this to use bit fields, something like

class MyClass
{
'
'
  struct Flags
  {
    unsigned Flag1:1;
    unsigned Flag2:1;
    unsigned Flag3:1;
  };
'
'
};

The one concern I have with making this switch is that I've come across a number of references on this site stating how slow bit fields are in C++. My assumption is that they are still faster than the manual code shown above, but is there any hard reference material covering the speed implications of using bit fields on various platforms, specifically 32bit and 64bit windows. The application deals with huge amounts of data in memory and must be both fast and memory efficient, which could well be why it was written this way in the first place.

+3  A: 

The two examples should be very similar in speed because the compiler will have to end up issuing pretty much the same instructions for bit-masking in both cases. To know which is really best, run a few simple experiments. But don't be surprised if the results are inconclusive; that's what I'm predicting...

You might be better saying that the bitfields are of type bool though.

Donal Fellows
+2  A: 

Unless this is in a very very very tight loop there will be nothing to choose between the two on performance, if performance really matters use bools (ie probably 32-bit values).

Using a struct with only three single bit fields like that will still pad out to at least 32-bits. If you're absolutely concentrated on saving every bit possible have a look at the documentation for your compiler on alignment and padding in structures.

EDIT: One reason to favour bit-fields though is that they make for neater code, and the importance of maintainability shouldn't be underestimated. In comparison to programmer time, computer time is cheap!

Autopulated
The example using 3 bits was possibly misleading, I actually have 128 bits of data across 4 unsigned integers, in a mix of single bit flags and short (3 - 7 bit) enumerations. Unfortunately space is as much of an issue as speed, and I need to maximise both even though they are in opposition. I'm already organising my structs to minimise padding and using #pragma pack(1) in some places as a last resort.
Shane MacLaughlin
In which case it sounds like you're doing everything that you can!However;if you have so many bits you could do some cunning things if they rarely differ from default values:for example, if on average << 1/8th of the bits are different from default, then you could use only a variable length array of bytes to store the indices of the bits that are different. Obviously there are performance implications though, and serious complications regarding memory allocation.
Autopulated
+1  A: 

General advice for this kind of question: set up a simple program comparing your situation as exactly as you can (operations, hardware, etc.) and measure your performance difference yourself.

For this question on bitfields vs masking, I doubt you'll see significant performance differences - the bitfield code may need a shift or two more than masking, depending on the compiler. Whether that's noticeable in your application or not is something you need to answer. There's a big difference in the considerations for mask-programmable embedded code vs. desktop applications, for example.

mpez0