bit-fields

What is the reason behind not allowing to access a bit field in C using its address, is it cause it might not be an address that is not system word aligned ..? or as it doesn't make sense to get bit's address within a byte...?(cause this types pointer arithmetic will be awkward ?) Bits do not have addresses. That's why you can't refer to them by address. The granularity of addressing is the char . I guess the reasoning is that the language was design to match the architecture it targeted, and I know of no machine which allows addressing of individual bits. The smallest unit of addressable

I would like to define a large bitfield for the purpose of quickly monitoring the status a very large structure of elements. Here is what I have so far: #define TOTAL_ELEMENTS 1021 typedef struct UINT1024_tag { UINT8 byte[128]; } UINT1024; typedef struct flags_tag { UINT1024:TOTAL_ELEMENTS; } flags_t; When I try compiling this, I get the error message, "error: bit-field `<anonymous>' has invalid type" Can bit-fields only be used on certain types? I thought that if I defined a large-enough variable, the massive bitfield needed for my application could then be defined because the bitfield has to

Although I have a good LSFR C implementation I thought I'd try the same in Haskell - just to see how it goes. What I came up with, so far, is two orders of magnitude slower than the C implementation, which begs the question: How can the performance be improved? Clearly, the bit-fiddling operations are the bottleneck, and the profiler confirms this. Here's the baseline Haskell code using lists and Data.Bits : import Control.Monad (when) import Data.Bits (Bits, shift, testBit, xor, (.&.), (.|.)) import System.Environment (getArgs) import System.Exit (exitFailure, exitSuccess) tap :: [[Int]] tap

Section 9.6/3 in C++11 is unusually clear: "A non-const reference shall not be bound to a bit-field." What is the motivation behind this prohibition? I understand that it's not possible to directly bind a reference to a bitfield. But if I declare something like this, struct IPv4Header { std::uint32_t version:4, // assumes the IPv4 Wikipedia entry is correct IHL:4, DSCP:6, ECN:2, totalLength:16; }; why can't I say this? IPv4Header h; auto& ecn = h.ECN; I'd expect the underlying code to actually bind to the entire std::uint32_t that contains the bits I'm interested in, and I'd expect read and

Does it make sense to qualify bit fields as signed / unsigned? Chris Young The relevant portion of the standard (ISO/IEC 9899:1999) is 6.7.2.1 #4: A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type. Yes. An example from here : struct { /* field 4 bits wide */ unsigned field1 :4; /* * unnamed 3 bit field * unnamed fields allow for padding */ unsigned :3; /* * one-bit field * can only be 0 or -1 in two's complement! */ signed field2 :1; /* align next field on a storage unit */ unsigned :0;

struct A { int a:2; int b:3; int c:3; }; int main() { struct A p = {2,6,1}; printf("\n%d\n%d\n%d\n",p.a,p.b,p.c); return 0; } Output is: -2,-2,1 What would be output of above code in C complier and in C++ complier? And Why? Your system seems to using 2's complement . A 2-bit bit-field holding 2 would be 10 in binary which is -2 in 2's complement system. Likewise 110(6) is -2 for a 3-bit representation in 2's complement. And 1 is plain 1 Also read about signed bit-fields here I get -2 -2 1 with my C compiler. The problem is that your bit fields are too small for the numbers you are trying to