Thread: How to use only 4 bytes of an int?

  1. #1
    Registered User
    Join Date
    Mar 2009
    Posts
    6

    How to use only 4 bytes of an int?

    I read somewhere a few weeks ago that you could allocate just 4 bytes to an integer by doing something like this:

    Code:
    int flag:0x4;
    I understand hex values and how to read them. Is this the correct way to do it (I can't find the site I read it from)?

  2. #2
    Ex scientia vera
    Join Date
    Sep 2007
    Posts
    477
    You are misunderstanding things. All types have certain sizes. An integer on a 32-bit system is normally 4 bytes.

    You can, however, tell the compiler you only want to use certain BITS of a type, which is what you are doing. Single bits cannot actually be stored, only single bytes, so you will always be allocating at least a byte, and the bits are actually being retrieved with bitwise arithmetic.
    "What's up, Doc?"
    "'Up' is a relative concept. It has no intrinsic value."

  3. #3
    Registered User
    Join Date
    Mar 2009
    Posts
    6
    Quote Originally Posted by IceDane View Post
    You are misunderstanding things. All types have certain sizes. An integer on a 32-bit system is normally 4 bytes.

    You can, however, tell the compiler you only want to use certain BITS of a type, which is what you are doing. Single bits cannot actually be stored, only single bytes, so you will always be allocating at least a byte, and the bits are actually being retrieved with bitwise arithmetic.
    Ya, my bad, I meant bit. So what I did there was, I only allocated one byte to the (modified) integer flag? If so, wouldn't the lowest anyone would ever want to go be (in order to avoid what I could imagine would be overhead from the bitwise arithmetic):

    Code:
    int flag:0x8;
    Or is the int still actually taking 4 bytes in memory, and we are only looking at one of those? I'd imagine this would be a memory saving tool.

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    The only valid use of bitfields is within structures (and classes in C++), where you can store multiple smaller integers in one larger unit:
    Code:
    struct a 
    {
        int x:4;
        int y:8;
        int z:4;
    };
    This struct will still take up 4 bytes, most likely, but you can store 3 different integer values there.

    If you want to have an array of bits, then you have to do it yourself. You can make an array of smaller integers, such as char or short, which will reduce the amount of space used.

    Using less than 8 bits at a time will most likely lead to extra code, and for most intents and purpose, will only be valuable if you have a HUGE number of these things. And, as I said earlier, it will have to involve writing your own code for it.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Mar 2009
    Posts
    6
    Thank you. That leads me to 2 questions. however: (1) Is it more cpu intensive to call an item in a structure than a local item, and (2) how do I learn what causes what type of overhead, ect (meaning, is there some way I can avoid asking questions like question 1 again based on some sort of reading I can do)? I'm quite interested in embedded systems, so that stuff is what I think about when programming.

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    A struct or a regular variable isn't any different in the instructions generated as a general rule.
    However, a bitfield (with number of bits different from the number of bits of char, short or int) WILL take more time to access because the compiler will have to produce the relevant and/or/shift instructions to modify the bits of the whole item.

    How to learn about these things? Basically, understand how the compiler works and study what it ACTUALLY generates compared to what you think it will do. I can almost always predict with good accuracy what instructions come out of a few lines of C or C++ code.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Registered User
    Join Date
    Mar 2009
    Posts
    6
    Well, it looks like I'm in for a serious Wikipedia session. Thanks again for the info.

  8. #8
    Registered User slingerland3g's Avatar
    Join Date
    Jan 2008
    Location
    Seattle
    Posts
    603
    matsp, wouldn't your struct be only 2 bytes in size and not 32 bits?

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by slingerland3g View Post
    matsp, wouldn't your struct be only 2 bytes in size and not 32 bits?
    Depends on the size of int itself. If you want to make it smaller, you probably need short instead of int. But I have a vague memory it is not clearly defined by the standard.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. memory leak
    By aruna1 in forum C++ Programming
    Replies: 3
    Last Post: 08-17-2008, 10:28 PM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  3. Replies: 2
    Last Post: 03-24-2006, 08:36 PM
  4. getting a headache
    By sreetvert83 in forum C++ Programming
    Replies: 41
    Last Post: 09-30-2005, 05:20 AM
  5. Quack! It doesn't work! >.<
    By *Michelle* in forum C++ Programming
    Replies: 8
    Last Post: 03-02-2003, 12:26 AM