bit-fields

问题 I came across a problem today where I discovered the way the bit fields in my bytes are ordered is dependent on the endianness of my processor. Take the next example: struct S { uint8_t a : 3; uint8_t b : 5; }; This struct takes one byte but the bit layout depends on the machine: Little endian: b4 b3 b2 b1 b0 a2 a1 a0 Big endian: a2 a1 a0 b4 b3 b2 b1 So on a little endian machine it starts filling from the LSB and on a big endian machine it start filling from the MSB. I once heard Stroustrup

问题 When I use this struct just after flashing device it works well, but after restarting (power on/off) using this struct(assign to any bit) cause a HardFault irq. I use Keil uVision with STM32F205. Why it not works? and what should I change/remove/add to fix it? Direct using GPIOC->ODR don't cause any problems what is wrong with bitfields in Kail? #pragma anon_unions typedef union { struct { __IO uint16_t Data_Bus:8; // 0-7 data bus __IO uint16_t Ctr_Pins:6; // 8-13 control pins __IO uint16_t

问题 To get a better handle and understanding of how bitfields, unions, and the byte alignment of structures work, I'm simulating a template Register structure. The requirements of my Register are as follows: Default size or width of a register is 8bits or 1 byte Larger size registers must be a multiple of 8 Registers are less than or equal 64 bits in size or 8 bytes. I have a set of structures which build off of each other in a cascading effect starting from the base unit of a Byte down to a

问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 5 years ago . From the Draft C++ Standard (N3337): 9.6 Bit-fields 4 If the value true or false is stored into a bit-field of type bool of any size (including a one bit bit-field), the original bool value and the value of the bit-field shall compare equal. If the value of an enumerator is

问题 When asking a question on how to do wrapped N bit signed subtraction I got the following answer: template<int bits> int sub_wrap( int v, int s ) { struct Bits { signed int r: bits; } tmp; tmp.r = v - s; return tmp.r; } That's neat and all, but how will a compiler implement this? From this question I gather that accessing bit fields is more or less the same as doing it by hand, but what about when combined with arithmetic as in this example? Would it be as fast as a good manual bit-twiddling

问题 We have data coming in over serial (Bluetooth), which maps to a particular structure. Some parts of the structure are sub-byte size, so the "obvious" solution is to map the incoming data to a bit-field. What I can't work out is whether the bit-endianness of the machine or compiler will affect it (which is difficult to test), and whether I should just abandon the bit-fields altogether. For example, we have a piece of data which is 1.5 bytes, so we used the struct: { uint8_t data1; // lsb uint8

问题 As part of a project I have a string of numbers between 0 and 3, for example: 2030000000000000000030000000000000000003333212111221121301 I want to pass this string through an URL, so I figured I could try using a bitfield since each number only uses a maximum of 2 bits each. I wrote the following functions in my class to convert such a string to and from an array of integers used as bitfields for the data: makeBuildBitfield: function(build) { var b = build.split(''); var f = [3, 0]; // the "3

问题 I'm a bit puzzled by how the following code gets layed out in memory: struct Thing { union { unsigned value:24; uint8_t bytes[3]; }; Thing(int v) :value(v) {} void foo() { printf("Thing %p value=%d !\n", this, value); } } __attribute__((__packed__)); On gcc 3.3, 4.3 or 4.6 on Linux (without any special options I can think of - only "-Wall -g" on 4.6), the size of the structure is always 4: $ pahole ./union struct Thing { union { unsigned int value; /* 4 */ unsigned char bytes[3]; /* 3 */ }; [

问题 I just want to know about following structure declarations. Which one is better to use for memory allocation and why? And what about padding in case of unsigned char and unsigned int? struct data{ unsigned char a:3; unsigned char b:4; }; and struct data{ unsigned int a:3; unsigned int b:4; }; 回答1: Bit fields should be declared with type signed int , unsigned int . Other types may or may not be supported. From Atmel in the C Standard, only “unsigned (int)” and “int” are acceptable datatypes

问题 I know that bit-field are compiler dependant, but I haven't find documentation about thread safety on bit-field with the latest g++ and Visual C++ 2010. Does the operations on a bit-field member are atomic ? 回答1: "Thread safe" is unfortunately a very overloaded term in programming. If you mean atomic access to bit-fields, the answer is no (at least on all processors I'm aware of). You have atomic access to 32bit memory locations on 32bit machines, but that only means you'll read or write a