C++ Bitsets

I am currently working on a device that has very limited library support and decided to rewrite the C++ bitset functions that are contained in STL. They won't mirror them exactly because some of the C++ syntax isn't supported in C.

I just have a question about one of my functions about whether or not I am dealing with undefined behavior. I want the function to be able to accept up to 32 bit integers (long).

While I was testing my function I got accurate results when I would send 8 bit numbers, but I am not sure if this would always be true.

Code:

---

//Counts the number of bits that are set to 1
unsigned long stl_count (unsigned long data)
{
        unsigned short i, j;
        j = 0;

        for (i = 0; i < sizeof(data) * 8; i++)
                if (data & (0x01 << i))
                        j++;

        return j;
}

---

As you can see, no matter what this will be checking all of the bits of a long. If I only sent, lets say 0xFF, would this loop be checking bits that aren't what I want, or does the argument "data" reserve all of that space.

Sorry if this was a bit long winded. I also have open ears to suggestions about better ways to do this.

Quote:

---

As you can see, no matter what this will be checking all of the bits of a long. If I only sent, lets say 0xFF, would this loop be checking bits that aren't what I want, or does the argument "data" reserve all of that space.

---

What do you mean?

By the way, i should be a size_t and j should be an unsigned long to match the return type, though it probably does not really matter. 8 should be replaced by CHAR_BIT.

Ok, here is what I am trying to ask.

Say I send 0xFF to my function, is it converted to 0x000000FF or is it random 0x4D672AFF? In my tests it seems to always be the former case, but that could just be my luck when I play with undefined behavior.

Quote:

---

Originally Posted by carrotcake1029

Ok, here is what I am trying to ask.

Say I send 0xFF to my function, is it converted to 0x000000FF or is it random 0x4D672AFF? In my tests it seems to always be the former case, but that could just be my luck when I play with undefined behavior.

---

0xFF == 0x00FF == 0x0000...000FF
The same as regular math, there is an implicit infinit number of 0's before a number.

I realize this, I want to know how my function is dealing with memory.

Quote:

---

Say I send 0xFF to my function, is it converted to 0x000000FF or is it random 0x4D672AFF?

---

Quote:

---

I realize this, I want to know how my function is dealing with memory.

---

0xFF will definitely fit into an unsigned long, so there is nothing to worry about. Of course, you might want to be more explicit and use the literal 0xFFU instead.

When integers are promoted from one type to a larger type, values are preserved. So if you sent an int to a function expecting a long (on a system where they aren't the same size), a temporary long variable would be created with the same value as the int you passed.

Quote:

---

Say I send 0xFF to my function, is it converted to 0x000000FF or is it random 0x4D672AFF? In my tests it seems to always be the former case, but that could just be my luck when I play with undefined behavior.

---

If the "unused" bits were random, think about what would happen if you were to add 0xFF + 0xFF, of if you simply incremented 0xFF ...The math would be wrong!!!!!

The leading bits must be zero! The number of total bits depends on the variable type, of course. (With a signed integers you might need to watch-out for the sign-bit, and the math can be wrong if you overflow.)

Quote:

---

Originally Posted by carrotcake1029

Say I send 0xFF to my function, is it converted to 0x000000FF or is it random 0x4D672AFF?

---

Think about it. If you assign an int to a long, the *value* of the long ought to be the same as the int, right? You just have more space for it now.

QuantumPete