Bitfields

Discussion in 'C++' started by Jon Slaughter, Jun 27, 2005.

  1. 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, Jun 27, 2005
    #1
    1. Advertising

  2. 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).
     
    Jon Slaughter, Jun 27, 2005
    #2
    1. Advertising

  3. Jon Slaughter

    Sensei Guest

    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.
     
    Sensei, Jun 27, 2005
    #3
  4. Jon Slaughter

    msalters Guest

    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
     
    msalters, Jun 29, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Juha Kettunen
    Replies:
    9
    Views:
    370
    Leor Zolman
    Apr 10, 2004
  2. Régis Troadec

    About bitfields

    Régis Troadec, Feb 14, 2004, in forum: C Programming
    Replies:
    8
    Views:
    422
    Dan Pop
    Feb 17, 2004
  3. rohit
    Replies:
    23
    Views:
    1,779
    Dave Thompson
    Jun 10, 2004
  4. Grumfish
    Replies:
    2
    Views:
    379
    Bengt Richter
    Aug 19, 2003
  5. GalenTX

    Bitfields in a heterogenous environment

    GalenTX, Feb 4, 2005, in forum: C Programming
    Replies:
    6
    Views:
    334
    GalenTX
    Feb 6, 2005
Loading...

Share This Page