Re: Bit field vs bit manipulation?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

I'm not sure what you are really trying to achieve. Do you actually
output a garbage (for example zero) byte after each 3 bytes and
then read it back in order to ensure proper in-memory alignment?

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"David Bender" <DavidBender@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:051B1374-EC3E-4E94-917D-9FD992A65C8B@xxxxxxxxxxxxxxxx
"Ondrej Spanel" wrote:

Example:

struct twelve {
WORD high : 12;
WORD low : 12;
} parts;

low = (( byte.b & 0x0f) * 256) + byte.c;
high= ((byte.b & 0xf0) >> 4) + (byte.a * 16);

First is definitely more readable. Second may be preferred when you need
to
maintain crossplatform compatibility of the data layout, as ordering of
items in bitfieds may vary between compilers / CPU architectures. Even if
you use second, I would probably avoid manipulating bytes and write the
code
as:

low = ( input& 0xfff );
high = ( input & 0xfff000 )>>12;

This is much better readable and it will actually even perform a lot
better
than your example.

If your intention was to have the data stored or accessed as three bytes
in
the memory, then you will need to use a code like your second version, as
bitfield storage is always represented as 32b int.

Regards
Ondrej


Thanks! That is a great help. I did figure it out later and simple
used the following to achieve my goal;

union groups {
struct bits {
unsigned int high : 12;
unsigned in low : 12;
const unisgned : 8;
} bit;
struct bytes {
unsigned char msb;
unsigned char nsb;
unsigned char lsb;
} byte;
} group;

The most important goal was not to corrupt data everytime I read a new
byte. Which is fixed now. Using the above "union" to build a table of
12 bit values, only once because I dont care about repeats at this time.

Thanks.


.

Relevant Pages

  • [git] m68k
    ... static volatile struct baboon *baboon; ... +static unsigned char baboon_disabled; ... -void baboon_irq_enable(int irq) { ... int baboon_irq_pending ...
    (Linux-Kernel)
  • Re: [RFC] [PATCH 1/1] input/touchscreen: Synaptics Touchscreen Driver
    ... Initial driver for Synaptics touchscreens using RMI4 protocol. ... +struct rmi_function_descriptor { ... unsigned char commandBaseAddr; ...
    (Linux-Kernel)
  • [patch v1.2.35] WAN: add driver retina
    ... static unsigned int find_cnt; ... struct fepci_card_private *cp) ... goto INVALID; ... (unsigned char __user *) ...
    (Linux-Kernel)
  • Re: structure padding
    ... > aggregate data types in order to access the members of the aggregate ... > struct { ...
    (comp.lang.c)
  • Re: Magic structs
    ... unsigned char data; ... It seems to me that a struct Ustr will only occupy 1-byte of memory, ... for the users of the library it looks like a "normal" string API ...
    (comp.lang.c)