From what I've read so far, it seems that reference variables are not supposed to take any memory at all. Instead they are treated as the exact same variable they are referencing but with another name.
However, when I ran the following code, it seems that it is not always the case:
#include
struct A
{
int m[3];
};
struct B: A
{
B():x(m[0]), y(m[1]), z(m[2]){}
int& x;
int& y;
int& z;
};
int main(){
printf("%u, %u\n", sizeof(A), sizeof(B));
return 0;
}
Output:
12, 40
Why is B so much bigger than A?
Is there any other way I can access, for example, B.m[0] with B.x?
Answer
From what I've read so far, it seems that reference variables are not supposed to take any memory at all.
You should read further ;)
Seriously, references are not magic. So in the real world, somehow the object has to store the information about what object the reference is bound to. So while conceptually a reference has no size, it practically is very much like a pointer, and normally the compiler just uses pointers. The behavior that differs from that of pointers (not null, not reassignable, no need to dereference it) is enforced by the compiler at compile time.
So what you see is essentially the size of A plus padding plus the size of three pointers. I guess you're on a 64bit system where sizeof(int)
is 4 and sizeof(void*)
is 8:
12 bytes for the A subobject (4 for each int)
+ 4 bytes padding (to get to a multiple of 8 bytes)
+24 bytes for the 3 references/pointers in B (8 for each one)
--------------
40 bytes total
For your other question, given an object b
of type B
, you can access b.m[0]
directly as it is public in A
and publicly inherited. Giving it another name without the reference overhead you encountered is not possible.
No comments:
Post a Comment