1

Suppose we have a continuous process where we increment an unsigned char +1 or -1 and we want it to always stay in a range between 0 , 2^n - 1,lets say for example that this range is 0 , 15, I know that it is possible to do something like this:

unsigned char offset = 0;

while( condition )
{
    if(something)
    {
       offset += 1;
    }else
    {
       offset -= 1;
    }
    offset %= 16;
}

I wanted to know if it is possible to the same thing with bit fields, and whether it had any benefits:

unsigned char offset : 4;
offset = 0;

while( condition )
{
    if(something)
    {
       offset += 1;
    }else
    {
       offset -= 1;
    }
}

I am asking because if I understand it correctly, the first version will perform the % at every loop iteration, while the second will only do it ( if what I read is correct) when offset tries to overflow.

dvd280
  • 876
  • 6
  • 11
  • Arithmetic over- and under-flow of unsigned integers is well-defined. When you over- or under-flow an unsigned integer it will roll over. For example if you have `unsigned short v;` then `v = 65535; ++v;` will make `v` zero. And `v = 0; --v` will turn `v` into `65535`. – Some programmer dude Oct 14 '20 at 08:34
  • Right. There is no *unsigned overflow*, when you reach the max for the unsigned type, it will be reduced modulo back to 0. – David C. Rankin Oct 14 '20 at 08:34
  • @DavidC.Rankin yeah I understand that, my question was whether it is correct to assume that the second version is safe and faster due to less `%` calls? – dvd280 Oct 14 '20 at 08:37
  • 1
    That I can't give you a yes/no on without going back to the standard and reading the bitfield section again on structs -- there are a few limitation that apply directly to bitfields -- and I have this nagging feeling that a bitfield cannot be treated as a type for this purpose. It's type is `unsigned char` so if you are expecting the 4-bits carved out by it to behave as a full type -- I don't think it does for this purpose. – David C. Rankin Oct 14 '20 at 08:55
  • [C11 Standard - 6.2.6 Representations of types(p4)](http://port70.net/~nsz/c/c11/n1570.html#6.2.6.1p4) specifically excludes the word "type" when describing the m:bits that make up a bit-field. So jury is still out on that one... – David C. Rankin Oct 14 '20 at 09:04
  • @DavidC.Rankin "A bit-field is interpreted as having a signed or unsigned integer type consisting of the specified number of bits", whatever that means. – n. m. could be an AI Oct 15 '20 at 13:50
  • Safe? Yes. Faster? Who knows, depends on a zillion factors. If you want to squeeze the last bit of performance out of your code, asking stackoverflow won't help you, you need to actually measure and compare versions of *your* program in *your* environment. – n. m. could be an AI Oct 15 '20 at 13:56
  • In C, according to how bitfields are defined in the spec, the answer to the OP's question about whether overflow results in modulo-reduction is: yes. (see https://stackoverflow.com/questions/4908300/overflow-in-bit-fields). Is there any reason to suspect that this is not also the case in C++? – saxbophone Apr 14 '22 at 21:59
  • Does this answer your question? [Overflow in bit fields](https://stackoverflow.com/questions/4908300/overflow-in-bit-fields) – saxbophone Apr 14 '22 at 22:00

0 Answers0