Can anyone explain to me what is going on here? First off, I think most programmers know that a class with a virtual function has a vtbl and thus has 4 extra bytes on the top of it. As far as I know, that's fairly standard. I've tested this and taken advantage of this fact before to do load in place from a binary file with patched vtbls. For the last 6 months, I've been working in Xcode and just recently came across the need to do some load in place stuff, so I was looking into patching vtbls again. Just to make sure my understanding was correct, I wrote a sample program. Here it is:
class A
{
public:
virtual int getData()
{
return a;
}
virtual void print()
{
printf("hello\n");
}
int a;
};
class B : public A
{
public:
int getData()
{
return b;
}
int b;
};
class C : public B
{
public:
int getData()
{
return c;
}
void print()
{
printf("world\n");
}
int c;
};
class D
{
public:
int a;
int b;
};
int main (int argc, const char * argv[])
{
A* tA = new A();
tA->a = 1;
printf("A: %d\n", sizeof(A));
printf("A data: %d\n", tA->getData());
B* tB = new B();
tB->a = 2;
tB->b = 4;
printf("B: %d\n", sizeof(B));
printf("B data: %d\n", tB->getData());
C* tC = new C();
tC->c = 8;
printf("C: %d\n", sizeof(C));
printf("C data: %d\n", tC->getData());
A* aC = tC;
aC->print();
printf("D: %d\n", sizeof(D));
return 0;
}
My expected output was:
A: 8
A data: 1
B: 12
B data: 4
C: 16
C data: 8
world
D: 8
However, the output I'm getting is:
A: 16
A data: 1
B: 16
B data: 4
C: 24
C data: 8
world
D: 8
Anybody have any idea what's going on here? Thanks!
Instances of classes A through C contain a vptr, a pointer to the virtual function table for the dynamic type. This pointer occupies 8 bytes on your 64-bit machine (or 4 bytes on a 32-bit machine). Each int member takes up 4 bytes.
The minimum value of sizeof(Class) is the sum of sizeof(member) for all members. If it were like that, then
sizeof(A) = 8 (vptr) + 4 (int a) = 12
sizeof(B) = 8 (vptr) + 4 (int a) + 4 (int b) = 16
sizeof(C) = 8 (vptr) + 4 (int a) + 4 (int b) + 4 (int c) = 20
sizeof(D) = 4 (int a) + 4 (int b) = 8
However, this is only the minimum size. Compilers usually increase this size to a multiple of sizeof(void*), which is 8 bytes here. This process is called aligning. It may look like this wastes memory, but this is outweighed by a performance gain: The CPU can read aligned data much faster than non-aligned data.
By the way, your expected result would have been correct if you were on a 32-bit machine. Pointers (esp. vptr) are 4 bytes wide there, and alignment is also to multiples of 4 bytes. Since all data members of the classes in question are 4 bytes big then, alignment wouldn't do anything there.
Related
I was playing around with memcpy when I stumbled on a strange result, where a memcpy that is called on the same pointer of memory after bool memcpy gives unexpected result.
I created a simple test struct that has a bunch of different type variables. I cast the struct into unsigned char pointer and then using memcpy I copy data from that pointer into separate variables. I tried playing around the offset of memcpy and shifting the int memcpy before bool (changed the layout of test struct so that the int would go before the bool too). Suprisingly the shifting fixed the problem.
// Simple struct containing 3 floats
struct vector
{
float x;
float y;
float z;
};
// My test struct
struct test2
{
float a;
vector b;
bool c;
int d;
};
int main()
{
// I create my structure on the heap here and assign values
test2* test2ptr = new test2();
test2ptr->a = 50;
test2ptr->b.x = 100;
test2ptr->b.y = 101;
test2ptr->b.z = 102;
test2ptr->c = true;
test2ptr->d = 5;
// Then turn the struct into an array of single bytes
unsigned char* data = (unsigned char*)test2ptr;
// Variable for keeping track of the offset
unsigned int offset = 0;
// Variables that I want the memory copied into they
float a;
vector b;
bool c;
int d;
// I copy the memory here in the same order as it is defined in the struct
std::memcpy(&a, data, sizeof(float));
// Add the copied data size in bytes to the offset
offset += sizeof(float);
std::memcpy(&b, data + offset, sizeof(vector));
offset += sizeof(vector);
std::memcpy(&c, data + offset, sizeof(bool));
offset += sizeof(bool);
// It all works until here the results are the same as the ones I assigned
// however the int value becomes 83886080 instead of 5
// moving this above the bool memcpy (and moving the variable in the struct too) fixes the problem
std::memcpy(&d, data + offset, sizeof(int));
offset += sizeof(int);
return 0;
}
So I expected the value of d to be 5 however it becomes 83886080 which I presume is just random uninitialized memory.
You ignore the padding of your data in a struct.
Take a look on the following simplified example:
struct X
{
bool b;
int i;
};
int main()
{
X x;
std::cout << "Address of b " << (void*)(&x.b) << std::endl;
std::cout << "Address of i " << (void*)(&x.i) << std::endl;
}
This results on my PC with:
Address of b 0x7ffce023f548
Address of i 0x7ffce023f54c
As you see, the bool value in the struct takes 4 bytes here even it uses less for its content. The compiler must add padding bytes to the struct to make it possible the cpu can access the data directly. If you have the data arranged linear as written in your code, the compiler have to generate assembly instructions on all access to align the data later which slows down your program a lot.
You can force the compiler to do that by adding pragma pack or something similar with your compiler. All the pragma things are compiler specific!
For your program, you have to use the address if the data for the memcpy and not the size of the data element before the element you want to access as this ignore padding bytes.
If I add a pragma pack(1) before my program, the output is:
Address of b 0x7ffd16c79cfb
Address of i 0x7ffd16c79cfc
As you can see, there are no longer padding bytes between the bool and the int. But the code which will access i later will be very large and slow! So avoid use of #pragma pack at all!
You've got the answer you need so I'll not get into detail. I just made an extraction function with logging to make it easier to follow what's happening.
#include <cstring>
#include <iostream>
#include <memory>
// Simple struct containing 3 floats
struct vector {
float x;
float y;
float z;
};
// My test struct
struct test2 {
float a;
vector b;
bool c;
int d;
};
template<typename T>
void extract(T& dest, unsigned char* data, size_t& offset) {
std::uintptr_t dp = reinterpret_cast<std::uintptr_t>(data + offset);
size_t align_overstep = dp % alignof(T);
std::cout << "sizeof " << sizeof(T) << " alignof " << alignof(T) << " data "
<< dp << " mod " << align_overstep << "\n";
if(align_overstep) {
size_t missing = alignof(T) - align_overstep;
std::cout << "misaligned - adding " << missing << " to align it again\n";
offset += missing;
}
std::memcpy(&dest, data + offset, sizeof(dest));
offset += sizeof(dest);
}
int main() {
std::cout << std::boolalpha;
// I create my structure on the heap here and assign values
test2* test2ptr = new test2();
test2ptr->a = 50;
test2ptr->b.x = 100;
test2ptr->b.y = 101;
test2ptr->b.z = 102;
test2ptr->c = true;
test2ptr->d = 5;
// Then turn the struct into an array of single bytes
unsigned char* data = reinterpret_cast<unsigned char*>(test2ptr);
// Variable for keeping track of the offset
size_t offset = 0;
// Variables that I want the memory copied into they
float a;
vector b;
bool c;
int d;
// I copy the memory here in the same order as it is defined in the struct
extract(a, data, offset);
std::cout << "a " << a << "\n";
extract(b, data, offset);
std::cout << "b.x " << b.x << "\n";
std::cout << "b.y " << b.y << "\n";
std::cout << "b.z " << b.z << "\n";
extract(c, data, offset);
std::cout << "c " << c << "\n";
extract(d, data, offset);
std::cout << "d " << d << "\n";
std::cout << offset << "\n";
delete test2ptr;
}
Possible output
sizeof 4 alignof 4 data 12840560 mod 0
a 50
sizeof 12 alignof 4 data 12840564 mod 0
b.x 100
b.y 101
b.z 102
sizeof 1 alignof 1 data 12840576 mod 0
c true
sizeof 4 alignof 4 data 12840577 mod 1
misaligned - adding 3 to align it again
d 5
24
There are apparently three padding bytes between the bool and the subsequent int. This is allowed by the standard due to alignment considerations (accessing a 4 byte int that is not aligned on a 4 byte boundary may be slow or crash on some systems).
So when you do offset += sizeof(bool), you are not incrementing enough. The int follows 4 bytes after, not 1. The result is that the 5 is not the first byte you read but the last one - you are reading three padding bytes plus the first one from test2ptr->d into d. And it is no coincidence that 83886080 = 2^24 * 5 (the padding bytes were apparently all zeros).
This question already has answers here:
How is the size of a C++ class determined?
(4 answers)
Closed 7 years ago.
Can anyone explain, why size of the objC is 8, not 12?
I think, that if it in the class C I have object with type int and in A, B - char, then after creation of the objC it should be 4 bytes for objA, objB and ObjC.
class A {
char a;
};
class B : A {
char b;
};
class C : B {
int c;
};
int main()
{
A objA;
B objB;
C objC;
cout << sizeof(objA) << endl; // 1
cout << sizeof(objB) << endl; // 2
cout << sizeof(objC) << endl; // 8! Why not 12?
return 0;
}
Edit 1:
In this case sizeof(objC) will be 12:
class A {
char a;
};
class B : A {
int b; // Here is int
};
class C : B {
char c; // Here is char
};
I believe that class C will have:
2x 1-byte chars
2-bytes of padding, so the int starts on a 4-byte boundary.
1x 4-byte integer
Making a total of 8-bytes
To keep the integer aligned on a boundary, there'll be 2-bytes of padding, making 8 bytes.
How do you get 12??
In your second example, class C will have:
a 1-byte char.
3-bytes of padding before the int. (keep the int on a 4-byte boundary)
a 4-byte int.
a 1-byte char.
Making a total of 9-bytes.
Sizes are rounded up to the nearest 4-bytes, which is 12.
In the first case, there is one padding. In the second case there are two paddings.
The first case will be:
+---+---+---+---+---+---+---+---+
| a | b | | | c |
+---+---+---+---+---+---+---+---+
<- 4 ->|<- 4 ->|
The second case will be:
+---+---+---+---+---+---+---+---+---+---+---+---+
| a | | | | b | c | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+
<- 4 ->|<- 4 ->|<- 4 ->|
This question already has an answer here:
Create a 10-bit data type in C/C++ [closed]
(1 answer)
Closed 6 years ago.
Is it possible to define some odd sized data type instead of the standard types using type-def like 10 bit or 12 bit in C++ ?
You can use a bitfield for that:
struct bit_field
{
unsigned x: 10; // 10 bits
};
and use it like
bit_field b;
b.x = 15;
Example:
#include <iostream>
struct bit_field
{
unsigned x: 10; // 10 bits
};
int main()
{
bit_field b;
b.x = 1023;
std::cout << b.x << std::endl;
b.x = 1024; // now we overflow our 10 bits
std::cout << b.x << std::endl;
}
AFAIK, there is no way of having a bitfield outside a struct, i.e.
unsigned x: 10;
by itself is invalid.
Sort of, if you use bit fields. However, bear in mind that bit fields are still packed within some intrinsic type. In the example pasted below, both has_foo and foo_count are "packed" inside of an unsigned integer, which on my machine, uses four bytes.
#include <stdio.h>
struct data {
unsigned int has_foo : 1;
unsigned int foo_count : 7;
};
int main(int argc, char* argv[])
{
data d;
d.has_foo = 1;
d.foo_count = 42;
printf("d.has_foo = %u\n", d.has_foo);
printf("d.foo_count = %d\n", d.foo_count);
printf("sizeof(d) = %lu\n", sizeof(d));
return 0;
}
Use Bitfields for this. Guess this should help http://www.cs.cf.ac.uk/Dave/C/node13.html#SECTION001320000000000000000
Why is gcc giving returning 13 as the sizeof of the following class ?
It seems to me that we should get e (4 bytes) + d (4 bytes) + 1 byte (for a and b) = 9 bytes. If it was alignment, aren't most 32 bit systems aligned on 8 byte boundaries ?
class A {
unsigned char a:1;
unsigned char b:4;
unsigned int d;
A* e;
} __attribute__((__packed__));
int main( int argc, char *argv[] )
{
cout << sizeof(A) << endl;
}
./a.out
13
You are very likely running on a 64 bit platform and the size of the pointer is not 4 but 8 bytes. Just do a sizeof on A * and print it out.
The actual size of structs with bitfields is implementation dependent, so whatever size gcc decides it to be would be right.
This should be simple but I have no clue where to look for the issue:
I have a struct:
struct region
{
public:
long long int x;
long long int y;
long long int width;
long long int height;
unsigned char scale;
};
When I do sizeof(region) it gives me 40 when I am expecting 33.
Any ideas?
(mingw gcc, win x64 os)
It's padding the struct to fit an 8-byte boundary. So it actually is taking 40 bytes in memory - sizeof is returning the correct value.
If you want it to only take 33 bytes then specify the packed attribute:
struct region
{
public:
long long int x;
long long int y;
long long int width;
long long int height;
unsigned char scale;
} __attribute__ ((packed));
long long int values are 8 bytes each. scale is only 1 byte but is padded for alignments, so it effectively takes up 8 bytes too. 5*8 = 40.
As others said, structs are padded for alignments, and such padding not only depends on the type of the members, but also on the order of the members in which they're defined.
For example, consider these two structs A and B as defined below. Both structs are identical in terms of members and types; the only difference is that the order in which members are defined isn't same:
struct A
{
int i;
int j;
char c;
char d;
};
struct B
{
int i;
char c;
int j;
char d;
};
Would the sizeof(A) be equal to sizeof(B) just because they've same number of members of same type? No. Try printing the size of each:
cout << "sizeof(A) = "<< sizeof(A) << endl;
cout << "sizeof(B) = "<< sizeof(B) << endl;
Output:
sizeof(A) = 12
sizeof(B) = 16
Surprised? See the output yourself : http://ideone.com/yCX4S