A use for bit fields

[jwes]

I discovered if I define a structure with bitfields that is equivalent to some packed data, I can use a cast in my debugger to view the data as if it were unpacked.

[bob]

I discovered if I define a structure with bitfields that is equivalent to some packed data, I can use a cast in my debugger to view the data as if it were unpacked.

Yes, but every compiler I have tried does ugly things to produce the code to extract the fields. Lots of sign extension stuff and other things that make it quite slow compared to doing your own AND/OR/SHIFT/etc stuff...

[bob]

I discovered if I define a structure with bitfields that is equivalent to some packed data, I can use a cast in my debugger to view the data as if it were unpacked.

Yes, but every compiler I have tried does ugly things to produce the code to extract the fields. Lots of sign extension stuff and other things that make it quite slow compared to doing your own AND/OR/SHIFT/etc stuff...

[sje]

Be cautious with C/C++ bit field usage. As Bob has mentioned, accessing code generated by a compiler can be far from optimal with respect to both space and time. Also, there is no guarantee that the bit field layout will be the same from compiler version to compiler version and in fact, it usually isn't the same for compilations done for different target architectures. This means that it is unwise to ever externalize data that has a C/C++ bit field substructure.

It's better to use your own handcrafted accessing functions for packed data.

[jwes]

I discovered if I define a structure with bitfields that is equivalent to some packed data, I can use a cast in my debugger to view the data as if it were unpacked.

Yes, but every compiler I have tried does ugly things to produce the code to extract the fields. Lots of sign extension stuff and other things that make it quite slow compared to doing your own AND/OR/SHIFT/etc stuff...

Note that I did not suggest using bit fields in the code, only having an equivalent struct with bit fields to allow me to use the debugger to view unpacked data.

[rbarreira]

Yeah that sounds like a good idea, probably not portable but that's OK if it's just used for debugging.

[Mincho Georgiev]

Using of bit fields could be an elegant solution in some cases when code simplicity is important. However, one should every time check manually how they are translated by the particular compiler, and if it comes down to speed issues, choose complexity instead. This goes down to many things in programming and I had many discussions with C++ programmers, trying to convince me to choose for example virtual functions in a specific case. If it's a matter of speed, forget the elegance (explicitly IMHO).

[rbarreira]

It seems most people aren't understanding what the OP meant. Notice the part where he talks about a cast and a debugger, he's just talking about creating an unused struct for the purpose of being viewed in a debugger.

[Mincho Georgiev]

It seems most people aren't understanding what the OP meant. Notice the part where he talks about a cast and a debugger, he's just talking about creating an unused struct for the purpose of being viewed in a debugger.

You're right, but it's better when the discussion gets stretched, right?

[CThinker]

I normally just create a "union". The bit field parts are there for visual debugging, but in the code, the 'parts' are accessed/modified using the less readable shift/and/or operations.