bit-fields

The field part of bit-fields seems to suggest that they can only be fields inside a structure or union. Can a bit-field be a typical "stand-alone" variable, outside any aggregate data-type like union or structure as follows: int sum:6; //Can this work as a declaration statement? sum=4; If not, why so? If bit-fields are basically intended to use less memory, why can't we declare any variable as a bit-field if we know it won't exceed that size? Bit-fields are only part of structs or unions because that's what the C standard allows. It would have been possible to decide differently. Why the

I've come across many comments on various questions regarding bitfields asserting that bitfields are non-portable, but I've never been able to find a source explaining precisely why. At face value, I would have presumed all bitfields merely compile to variations of the same bitshifting code, but evidently there must be more too it than that or there would not be such vehement dislike for them. So my question is what is it that makes bitfields non-portable? Bit fields are non-portable in the same sense as integers are non-portable. You can use integers to write a portable program, but you

Is it possible to marshal a C-style struct containing bit-fields to a C# struct, or would you have to marshal it to a basic type and then do bit-masks? E.g. I would like to marshal from a C style structure like this: struct rgb16 { unsigned int R : 4; unsigned int G : 5; unsigned int B : 4; } And marshal it onto something like this: [StructLayout(LayoutKind.Sequential)] public struct Rgb16 { public byte R; public byte G; public byte B; } There are no bit-fields in C#. So I'd go with properties that encapsulate the bit fiddling: [StructLayout(LayoutKind.Sequential)] public struct Rgb16 {

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 good after all? Should I reconsider the common best-practice advice to never use bitfields? Rohit

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 defining a struct that conforms to the RawOptionSet protocol: struct NSCalendarUnit : RawOptionSet { init(_

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? Not sure if I understand it well, but I see that while first compiler compresses the struct to 9+7 = 16 bits, the other

I made a bit field with a field sized 1 bit, and used int instead of unsigned . Later on when i tried to check the value of the field i found that the value was -1. I used this code to check the binary represantation and the value of my bit field: #include <stdio.h> #include <stdlib.h> union { struct { int bit:1; } field; int rep; } n; int main() { int c, k; n.field.bit=1; for (c = 31; c >= 0; c--) { k = n.rep >> c; if (k & 1) printf("1"); else printf("0"); } printf("\n %d \n", n.field.bit); return 0; } the output was: 00000000000000000000000000000001 -1 In that case, why is the value of my