3 ms·

I'm not sure what you mean. If you meant "why worry about bits, you should be dealing with values", then there are plenty of cases where that isn't true. Lots

by edanm 16y ago

I'm not sure what you mean. If you meant "why worry about bits, you should be dealing with values", then there are plenty of cases where that isn't true. Lots of programs (e.g. embedded programs) have to deal with actual bits, not with the values themselves. Just as an example, flags. (I don't know if this is what you meant, so apologies if I misunderstood your question.)

jrockway 16y ago
So why not have a type that's "bitfield64" or something, and not worry how the machine represents your integer. This seems like too much abstraction for a C programmer, I know, but there is already precedent. int and int * are not the same type; if you use one as the other the compiler will tell you not to, even though they are the exact same bits in memory.
- edanm 16y ago
  That's a great idea, actually. In the projects I worked on, there were usually typedefs of various sizes, for example byte -> unsigned char, word -> unsigned int, dword -> unsigned long, etc. We made sure that each one of these had the correct bit amounts in the mapping, and that way, you always knew exactly how many bits you were working with, which is important in embedded systems (where memory is important, and where you usually have structures which directly map to e.g. ip headers, so you need exact sizes). By the way, even the words byte/word/dword might cause confusion, cause none of them are well defined either. Some architectures assign a word 16 bits, some 32 bits. And believe it or not, some architectures even assign bytes a number of bits different than 8! The "officially correct" term, I believe, is Octet, which is defined as 8 bits. Of course, we just decided internally what we meant by byte, word and dword, and that worked fine.
philwelch 16y ago
Also bitmaps. There are a lot of bitmaps at the system level denoting, f.ex., used and unused inumbers and blocks. (Though it is easier--and more common--to initialize bitmaps to 0 than to initialize bitmaps to 1).

by edanm 16y ago

jrockway 16y ago

So why not have a type that's "bitfield64" or something, and not worry how the machine represents your integer. This seems like too much abstraction for a C programmer, I know, but there is already precedent. int and int * are not the same type; if you use one as the other the compiler will tell you not to, even though they are the exact same bits in memory.

edanm 16y ago
That's a great idea, actually. In the projects I worked on, there were usually typedefs of various sizes, for example byte -> unsigned char, word -> unsigned int, dword -> unsigned long, etc. We made sure that each one of these had the correct bit amounts in the mapping, and that way, you always knew exactly how many bits you were working with, which is important in embedded systems (where memory is important, and where you usually have structures which directly map to e.g. ip headers, so you need exact sizes). By the way, even the words byte/word/dword might cause confusion, cause none of them are well defined either. Some architectures assign a word 16 bits, some 32 bits. And believe it or not, some architectures even assign bytes a number of bits different than 8! The "officially correct" term, I believe, is Octet, which is defined as 8 bits. Of course, we just decided internally what we meant by byte, word and dword, and that worked fine.

philwelch 16y ago

Also bitmaps. There are a lot of bitmaps at the system level denoting, f.ex., used and unused inumbers and blocks. (Though it is easier--and more common--to initialize bitmaps to 0 than to initialize bitmaps to 1).