This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What does 'unsigned temp:3' mean?
please what does this notation mean
int a:16;
I found it is code like this and it does compile.
struct name {
int a:16; }
This is a bitfield.
This particular bitfield doesn't make much sense as you just could use a 16-bit type and you're wasting some space as the bitfield is padded to the size of int.
Usually, you are using it for structures that contain elements of bit size:
struct {
unsigned nibble1 : 4;
unsigned nibble2 : 4;
}
struct name { int a:16; }
It means a is defined as 16-bit memory space. The remaining bits (16 bits) from int can be used to defined another variable, say b, like this:
struct name { int a:16; int b:16; }
So if int is 32-bit (4 bytes), then the memory of one int is divided into two variables a and b.
PS: I'm assuming sizeof(int) = 4 bytes, and 1 byte = 8 bits
struct s
{
int a:1;
int b:2;
int c:7;
};/*size of structure s is 4 bytes and not 4*3=12 bytes since all share the same space provided by int declaration for the first variable.*/
struct s1
{
char a:1;
};/*size of struct s1 is 1byte had it been having any more char _var:_val it would have been the same.*/
It's a bitfield.
I've never seen a 16 bit bitfield; usually that's a short.
http://www.cs.cf.ac.uk/Dave/C/node13.html
Related
This question already has answers here:
Why isn't sizeof for a struct equal to the sum of sizeof of each member?
(13 answers)
Closed 5 years ago.
Why is this code:
#include <iostream>
struct S {
unsigned char a:6, b:6, c:6, d:6;
};
int main(int argc, char *argv[]) {
std::cout << sizeof(S);
return 0;
}
returning 4? Shouldn't it have a size of 4 x 6 = 24b = 3B? In contrast, this code:
struct S { unsigned char a:4, b:4, c:4, d:4; };
returns a 2, while this one:
struct S { unsigned char a:4, b:4, c:4, d:4, e:4, f:4; };
returns a 3...
From CppReference: Bit Fields:
The following properties of bit fields are implementation-defined:
[...]
Everything about the actual allocation details of bit fields within the class object
For example, on some platforms, bit fields don't straddle bytes, on others they do
So yes, it's implementation-defined (i.e., up to the compiler).
So, even though the compiler calculates the other 2 without padding, it adds padding the first one?
Yes, because in the first case, values would "straddle" byte borders if not padded, while in the other two examples, they don't.
Again, this is implementation-defined and could be handled differently on another platform, a different compiler on the same platform, or even a different version of the same compiler.
This question already has answers here:
Why isn't sizeof for a struct equal to the sum of sizeof of each member?
(13 answers)
Closed 5 years ago.
My c++ code
#include <iostream>
using namespace std ;
struct Node {
int data ;
struct Node *next;
};
int main(){
struct Node *head = NULL;
struct Node *second = NULL;
cout << sizeof(struct Node);
}
output to terminal
16
How is the size 16 ?
Size of int is 4bytes.
How come it's multiplied by 4 ?
Please can anyone give detailed calculation ?
Thanks !
An int is indeed 4 bytes (at least in x86 64 bit machines). A pointer (at least in x86 64 bit machines) is 8 bytes, so in theory the struct could have been 12 bytes. However, it's padded to a multiplication of the native word size (8 bytes) - and the closet round-up of 12 bytes would be 16 bytes.
Structures are packed to the size of "biggest word" used. Eg, if you have such structure:
struct ThreeBytes {
char one;
short two;
};
Its size will be 4 bytes, because field one will be padded to the size of short, i.e. there is unused byte after that filed. If two would be an int, the structure will have size of two ints. This happens if you align your structure to that:
// this structure got size of 4 bytes.
struct ThreeBytes {
char one;
char two;
short three;
};
And this is unaligned one:
// This structure will have size 6
struct ThreeBytes {
char one;
short two;
char three;
};
This is default behavior, there are compiler directives that allow change packing (see #pragma pack, for example, compiler means may be different). Essentially you can set the unit to which fields will be padded or disable padding by setting it to 1. But some platforms do not allow that at all.
I'd like to define an enum to be smaller than one byte while maintaining type safety.
Defining an enum as:
enum MyEnum : unsigned char
{
i ,j, k, w
};
I can shrink it to one byte, however I'd like to make it use only 2 bits since I will at most have 4 values in it. Can this be done?
In my struct where I use the enum, the following does not work
struct MyStruct
{
MyEnum mEnum : 2; // This will be 4 bytes in size
};
Thanks!
Update:
The questions comes from this scenario:
enum MyEnum : unsigned char
{
i ,j, k, w
};
struct MyStruct
{
union
{
signed int mXa:3;
unsigned int mXb:3;
};
union
{
signed int mYa:3;
unsigned int mYb:3;
};
MyEnum mEnum:2;
};
sizeof(MyStruct) is showing 9 bytes. Ideally I'd like the struct to be 1 bytes in size.
Update for implemented solution:
This struct is one byte and offers the same functionality and type safety:
enum MyEnum :unsigned char
{
i,j,k,w
};
struct MyStruct
{
union
{
struct { MyEnum mEnum:2; char mXa:3; char mXb:3;};
struct { MyEnum mEnum:2; unsigned char mYa:3; unsigned char mYb:3;};
};
};
As per standard definition, a types sizeof must be at least 1 byte. This is the smallest addressable unit of memory.
The feature of bitfields you are mentioning allows to define members of structures to have smaller sizes, but the struct itself may not be because
It must be of at least 1 byte too
Alignment considerations might need it to be even bigger
additionally you may not take the address of bitfield members, since as said above, a byte is the smallest addressable unit of memory (You can already see that by sizeofactually returning the number of bytes, not bits, so if you expected less than CHAR_BIT bits, sizeof would not even be able to express it).
bitfields can only share space if they use the same underlying type. And any unused bits are actually left unused; if the sum of bits in an unsigned int bitfield is 3 bits, it still takes 4 bytes total. Since both enums have unsigned int members, they're both 4 bytes, but since they are bitfields, they have an alignment of one. So the first enum is 4 bytes, and the second is four bytes, then the MyEnum is 1 byte. Since all of those have an alignment of one, no padding is needed.
Unfortunately, union doesn't really work with bitfields really at all. Bitfields are for integer types only. The most I could get your data to without serious redesign is 3 bytes: http://coliru.stacked-crooked.com/view?id=c6ad03c93d7893ca2095fabc7f72ca48-e54ee7a04e4b807da0930236d4cc94dc
enum MyEnum : unsigned char
{
i ,j, k, w
};
union MyUnion
{
signed char ma:3; //char to save memory
unsigned char mb:3;
};
struct MyStruct
{
MyUnion X;
MyUnion Y;
MyEnum mEnum;
}; //this structure is three bytes
In the complete redesign category, you have this: http://coliru.stacked-crooked.com/view?id=58269eef03981e5c219bf86167972906-e54ee7a04e4b807da0930236d4cc94dc
No. C++ defines "char" to be the smallest addressable unit of memory for the platform. You can't address 2 bits.
Bit packing 'Works for me'
#include <iostream>
enum MyEnum : unsigned char
{
i ,j, k, w
};
struct MyStruct
{
MyEnum mEnum : 2;
unsigned char val : 6;
};
int main()
{
std::cout << sizeof(MyStruct);
}
prints out 1. How / what are you measuring?
Edit: Live link
Are you doing something like having a pointer as the next thing in the struct? In which case, you'll have 30bits of dead space as pointers must be 4 byte aligned on most 32bit systems.
Edit: With your updated example, its the unions which are breaking you
enum MyEnum : unsigned char
{
i ,j, k, w
};
struct MyStruct
{
unsigned char mXb:3;
unsigned char mYb:3;
MyEnum mEnum:2;
};
Has size 1. I'm not sure how unions and bit packing work together though, so I'm no more help.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do I find the size of a struct?
Struct varies in memory size?
I am using following struct for network communication, It creates lots of unnecessary bytes in between.
It gives different size than expected 8 Bytes.
struct HttpPacket {
unsigned char x1;
union {
struct {
unsigned char len;
unsigned short host;
unsigned char content[4];
} packet;
unsigned char bytes[7];
unsigned long num;
}
And Following gives different size even though that I am removing a field from a union
struct HttpPacket {
unsigned char x1;
union {
struct {
unsigned char len;
unsigned short host;
unsigned char content[4];
} packet;
unsigned long num;
}
Also, A more clear example
struct {
unsigned char len;
unsigned short host;
unsigned char content[4];
} packet;
And it gives a size of 8, instead of 7.
And I add one more field, It still gives the same size
struct {
unsigned char EXTRAADDEDFIELD;
unsigned char len;
unsigned short host;
unsigned char content[4];
} packet;
Can someone please help on resolving this issue ?
UPDATE: I need the format to hold while transmitting the packet, So I want to skip these paddings
C makes no guarantees on the size of a struct. The compiler is allowed to line up the members however it wants. Usually, as in this case, it will make the size word-aligned since that's fastest on most machines.
Ever heard of alignment and padding?
Basically, to ensure fast access, certain types have to be on certain bounds of memory addresses.
This is called alignment.
To achieve that, the compiler is allowed to insert bytes into your data structure to achieve that alignment.
This is called padding.
By default, structure fields are aligned on natural boundaries. For example, a 4-byte field will start on a 4-byte boundary. The compiler inserts pad bytes to achieve this. You can avoid the padding by using #pragma pack(0) or other similar compiler directives
If you have a C99 compiler and can use the "new" fixed-width types: make an array of uint8_t and do the separation in members yourself.
uint8_t data[8];
x1 = data[0];
len = data[1];
host = data[2] * 256 + data[3]; /* big endian */
content[0] = data[4];
content[1] = data[5];
content[2] = data[6];
content[3] = data[7];
/* ... */
You can follow the same procedure in C89 if you can rely on CHAR_BIT being 8.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What does this C++ code mean?
I'm trying to map a C structure to Java using JNA. I came across something that I've never seen.
The struct definition is as follows:
struct op
{
unsigned op_type:9; //---> what does this mean?
unsigned op_opt:1;
unsigned op_latefree:1;
unsigned op_latefreed:1;
unsigned op_attached:1;
unsigned op_spare:3;
U8 op_flags;
U8 op_private;
};
You can see some variable being defined like unsigned op_attached:1 and I'm unsure what would that mean. Would that effect the number of bytes to be allocated for this particular variable?
This construct specifies the length in bits for each field.
The advantage of this is that you can control the sizeof(op), if you're careful. the size of the structure will be the sum of the sizes of the fields inside.
In your case, size of op is 32 bits (that is, sizeof(op) is 4).
The size always gets rounded up to the next multiple of 8 for every group of unsigned xxx:yy; construct.
That means:
struct A
{
unsigned a: 4; // 4 bits
unsigned b: 4; // +4 bits, same group, (4+4 is rounded to 8 bits)
unsigned char c; // +8 bits
};
// sizeof(A) = 2 (16 bits)
struct B
{
unsigned a: 4; // 4 bits
unsigned b: 1; // +1 bit, same group, (4+1 is rounded to 8 bits)
unsigned char c; // +8 bits
unsigned d: 7; // + 7 bits
};
// sizeof(B) = 3 (4+1 rounded to 8 + 8 + 7 = 23, rounded to 24)
I'm not sure I remember this correctly, but I think I got it right.
It declares a bit field; the number after the colon gives the length of the field in bits (i.e., how many bits are used to represent it).
unsigned op_type:9;
Means op_type is an integer variable with 9 bits.
The colon modifier on integral types specifies how many bits the int should take up.