Thread: Char size (in bytes) independent code

  1. #1
    *this
    Join Date
    Mar 2005
    Posts
    498

    Char size (in bytes) independent code

    The code I am currently working on assumes that a char is 1 byte long, and it depends on this assumption. If I wanted to make sure 8 bits are used could bit fields be a good alternative? Would it slow down my program if I had a bitfield on a char like so:

    Code:
    unsigned char one:8;
    Even though unsigned char is already 8 bits (on most machines), would it effect my program if it where 8 bits to begin with?

  2. #2
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >The code I am currently working on assumes that a char is 1 byte long
    A char is 1 byte, always. That's a guarantee made by the C++ standard.

    >If I wanted to make sure 8 bits are used
    You realize that a byte doesn't have to be eight bits, right? It does have to be at least eight bits though, and if your code assumes an octet then the best solution may be to refuse compilation for systems where CHAR_BIT is not 8:
    Code:
    #include <climits>
    
    #if CHAR_BIT != 8
    #error I don't like you
    #endif
    My best code is written with the delete key.

  3. #3
    *this
    Join Date
    Mar 2005
    Posts
    498
    Ya I thought it was only one byte but I read some articles and got confused... Thanks

  4. #4
    *this
    Join Date
    Mar 2005
    Posts
    498
    So would my code slow down the program even on systems where 1 byte is 8 bits?

    >The code I am currently working on assumes that a char is 1 byte long
    A char is 1 byte, always. That's a guarantee made by the C++ standard.
    Now I realize that its not the char itself but the actual byte, I meant to say that my program assumes 1 byte is 8 bits.
    Last edited by JoshR; 06-26-2005 at 07:23 PM.

  5. #5
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >So would my code slow down the program even on systems where 1 byte is 8 bits?
    Very likely, but it doesn't matter if the performance hit isn't measurably different when you profile the program. Try it and see.

    By the way, what are you doing that requires that each byte be an octet? Is possible that you could avoid that portability issue entirely through careful design.
    My best code is written with the delete key.

  6. #6
    *this
    Join Date
    Mar 2005
    Posts
    498
    It's this encryption algorithm I've been working on that moves blocks of bits around in a certain fassion and does some other tricks. When I first came up with the idea I wasn't aware of all the portability issues, but in the end I think it will be great because it can be used for network security across different types of systems because its also endian independent.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Adventures in labyrinth generation.
    By guesst in forum Game Programming
    Replies: 8
    Last Post: 10-12-2008, 01:30 PM
  2. memory leaks
    By TehOne in forum C Programming
    Replies: 4
    Last Post: 10-10-2008, 09:33 PM
  3. comparing fields in a text file
    By darfader in forum C Programming
    Replies: 9
    Last Post: 08-22-2003, 08:21 AM
  4. Replies: 11
    Last Post: 03-25-2003, 05:13 PM
  5. Strings are V important...
    By NANO in forum C++ Programming
    Replies: 15
    Last Post: 04-14-2002, 11:57 AM