bit-fields | 易学教程

What is VC++ doing when packing bitfields?

阅读更多关于 What is VC++ doing when packing bitfields?

To clarify my question, let's start off with an example program: #include <stdio.h> #pragma pack(push,1) struct cc { unsigned int a : 3; unsigned int b : 16; unsigned int c : 1; unsigned int d : 1; unsigned int e : 1; unsigned int f : 1; unsigned int g : 1; unsigned int h : 1; unsigned int i : 6; unsigned int j : 6; unsigned int k : 4; unsigned int l : 15; }; #pragma pack(pop) struct cc c; int main(int argc, char **argv) { printf("%d\n",sizeof(c)); } The output is "8", meaning that the 56 bits (7 bytes) I want to pack are being packed into 8 bytes, seemingly wasting a whole byte. Curious about

Is there a bit-equivalent of sizeof() in C?

阅读更多关于 Is there a bit-equivalent of sizeof() in C?

问题 Sizeof() doesn't work when applied to bitfields: # cat p.c #include<stdio.h> int main( int argc, char **argv ) { struct { unsigned int bitfield : 3; } s; fprintf( stdout, "size=%d\n", sizeof(s.bitfield) ); } # gcc p.c -o p p.c: In function ‘main’: p.c:5: error: ‘sizeof’ applied to a bit-field ...obviously, since it can't return a floating point partial size or something. However, it brought up an interesting question. Is there an equivalent, in C, that will tell you the number of bits in a

Justification for using a bitfield instead of EnumSet in modern Java 8 API

阅读更多关于 Justification for using a bitfield instead of EnumSet in modern Java 8 API

问题 EnumSet , as old as the enum itself (both since Java 5), is supposed to be a noncompromizing replacement for the use case of bitfields: as fast and lean as the bitfield (well, except for not being a primitive type), and typesafe to boot. On the other hand, the most recent and for years the most anticipated Java API—the Streams API—unashamedly employs bitfields for Spliterator 's characteristics. Should I consider the above as a clear admission by the core Java experts that EnumSet is not that

Declaring and using a bit field enum in Swift

阅读更多关于 Declaring and using a bit field enum in Swift

问题 How should bit fields be declared and used in Swift? Declaring an enum like this does work, but trying to OR 2 values together fails to compile: enum MyEnum: Int { case One = 0x01 case Two = 0x02 case Four = 0x04 case Eight = 0x08 } // This works as expected let m1: MyEnum = .One // Compiler error: "Could not find an overload for '|' that accepts the supplied arguments" let combined: MyEnum = MyEnum.One | MyEnum.Four I looked at how Swift imports Foundation enum types, and it does so by

sizeof(struct) different for different compilers

阅读更多关于 sizeof(struct) different for different compilers

问题 Supposing I have a code like this: #include <stdio.h> #include <stdint.h> int main(int argc, char *argv[]) { typedef struct{ uint16_t x : 9; uint8_t y : 7; } z; printf("sizeof(z) = %lu\n",sizeof(z)); } I have different results for clang on Mac (2) and someone told me on Windows it returned (3). Not sure if I understand it well, but I see that while first compiler compresses the struct to 9+7 = 16 bits, the other uses 16 bits of uint16_t and 8 of uint8_t. Could you advise? 回答1: Not sure if I

Why do bit fields in C need to be defined of type unsigned int or signed int [duplicate]

阅读更多关于 Why do bit fields in C need to be defined of type unsigned int or signed int [duplicate]

问题 This question already has answers here : Bit-fields of type other than int? (3 answers) Closed 5 years ago . I was running code quality check on my C project, which involves structures with bit fields. I came across a situation which, as per MISRA C 2004 standards, rule # 6.4 - is a violation, that reads as follows: "6.4 Bit fields shall only be defined to be of type unsigned int or signed int." Literature available on Microsoft Developer Network here asserts this. Can anyone explain as to

How is the size of a struct with Bit Fields determined/measured?

阅读更多关于 How is the size of a struct with Bit Fields determined/measured?

#include <stdio.h> typedef struct size { unsigned int a:1; unsigned int b:31; unsigned int c:1; } mystruct; int main() { mystruct a; printf("%d", sizeof(a)); return 0; } With int b:31 , the output is 8. With int b:1 , the output is 4. With int b:32 , the output is 12. Can somebody explain the reason for this? You don't say whether you know what bitfields are, but I'll assume you do. On your implementation, evidently unsigned int is a 32 bit integer, occupying 4 bytes. This accounts for the first and second examples. Clearly 3 bitfields totalling 33 bits don't fit into a single unsigned int ,

Can Microsoft store three-valued fields in a single bit?

阅读更多关于 Can Microsoft store three-valued fields in a single bit?

问题 I'm completely ignorant of SQL/databases, but I was chatting with a friend who does a lot of database work about how some databases use a "boolean" field that can take a value of NULL in addition to true and false. Regarding this, he made a comment along these lines: "To Microsoft's credit, they have never referred to that kind of field as a boolean, they just call it a bit. And it's a true bit - if you have eight or fewer bit fields in a record, it only requires one byte to store them all."

Type of unsigned bit-fields: int or unsigned int

阅读更多关于 Type of unsigned bit-fields: int or unsigned int

问题 Section 6.3.1.1 of the C99 standard contains: The following may be used in an expression wherever an int or unsigned int may be used: [...] A bit-field of type _Bool , int , signed int , or unsigned int . If an int can represent all values of the original type, the value is converted to an int ; otherwise, it is converted to an unsigned int . It seems to me that this implies that unsigned int bit-fields are promoted to int , except when the width of the unsigned bit-field is equal to the

Order of fields when using a bit field in C

阅读更多关于 Order of fields when using a bit field in C

I have a struct of the following type typedef struct { unsigned int a : 8; unsigned int b : 6; unsigned int c : 2; }x, *ptr; What i would like to do, is change the value of field c. I do something like the following x structure = { 0 }; x->c = 1; When I look at the memory map, I expect to find 00 01 , but instead I find 00 40 . It looks like when arranging the second byte, it puts c field in the lowest bits and b field in the highest bits. I've seen this on both GCC and Windows compilers. For now, what I do is the following, which is working OK. unsigned char ptr2 = (unsigned char*) ptr *(ptr2