Re: Inheritance and offsetof
On Sep 23, 11:28 am, "Francesco S. Carta" <entul...@gmail.com> wrote:
On 23 Set, 10:06, James Kanze <james.ka...@gmail.com> wrote:
On Sep 22, 11:05 pm, "Francesco S. Carta"
<entul...@gmail.com> wrote:
On 22 Set, 23:03, James Kanze <james.ka...@gmail.com> wrote:
[...]
No. The only thing a C-style cast can do that static_cast
or reinterpret_cast (combined with const_cast) can't is cast
to a private base class.
Uh... black magic... but, wait: GCC 3.4.5 allows me
reinterpret_cast- ing a derived class to all of its base
classes, even to private ones... is that a bug?
No. But it's not doing what you think---reinterpret_cast
doesn't cast up and down in a hierarchy; it tells the compiler
that the actual pointer you have points to some different type.
You're right and you got me on that, it didn't do _exactly_
what I thought, but still, it is going there. Read on please.
A reinterpret_cast reinterprets the type of a pointer or a
reference. It doesn't convert within the hierarchy.
To get an idea of what I mean, try the following:
#include <iostream>
struct A { int a ; } ;
struct B { int b ; } ;
struct C : A, B { int c ; } ;
int
main()
{
C obj ;
obj.a = 1 ;
obj.b = 2 ;
obj.c = 3 ;
C* pc = &obj ;
B* pb1 = static_cast< B* >( pc ) ;
B* pb2 = reinterpret_cast< B* >( pc ) ;
std::cout << "using static_cast: " << pb1 << " (" << pb1->b <<
")\n" ;
std::cout << "using reinterpret_cast: " << pb2 << " (" << pb2->b << ")\n" ;
}
Thanks for pointing this out. The first time I've tried it
only by calling functions of the base classes after having
used reinterpret_cast, hence I didn't realize that data
displacement problem.
Note that my code contains undefined behavior. I happen to know
what it does on the usual implementations (VC++, g++, etc.), but
there's absolutely no guarantee. I just posted it to show a
little what's going on under the hood.
But now that you have made me dig the problem further, I feel
to say that your original statement:
"The only thing a C-style cast can do that static_cast or
reinterpret_cast (combined with const_cast) can't is cast to a
private base class."
...does not apply _exactly_ as it is.
I know that I am nitpicking right now, I just want to show that we
never really need C-style casts, even when doing weird hacks.
Of course, since my knowledge is what it is, you might come up
with something else that cannot really be done without C-style
casts, and I'll eagerly learn something new, then.
Consider the following:
-------
#include <iostream>
#include <string>
using namespace std;
struct A {
string data;
A() : data("A's data") {}
string foo() {
return "A, private base";
}
};
struct B {
string data;
B() : data("B's data") {}
string foo() {
return "B, protected base";
}
};
struct C : private A, protected B {
string data;
C() : data("C's data") {}
string foo() {
return "C, derived class";
}
};
int main() {
C c;
cout << " &c == " << size_t(&c) << endl;
cout << "c.foo() == " << c.foo() << endl;
cout << " c.data == " << c.data << endl << endl;
And all of the remaining code is undefined behavior.
B& b = *reinterpret_cast<B*>(size_t(&c) + sizeof(A));
cout << " &b == " << size_t(&b) << endl;
cout << "b.foo() == " << b.foo() << endl;
cout << " b.data == " << b.data << endl << endl;
The above might work, or it might not. If A doesn't contain any
data members or virtual functions, it probably won't work on a
lot of implementations.
A& a = reinterpret_cast<A&>(c);
There's also no guarantee that the A subobject is at the same
physical address as the C object.
cout << " &a == " << size_t(&a) << endl;
cout << "a.foo() == " << a.foo() << endl;
cout << " a.data == " << a.data << endl;
return 0;
}
-------
And its output:
-------
&c == 2359120
c.foo() == C, derived class
c.data == C's data
&b == 2359124
b.foo() == B, protected base
b.data == B's data
&a == 2359120
a.foo() == A, private base
a.data == A's data
-------
I've got to a private base with just a reinterpret_cast. Fine,
it worked because A is the first base of C.
It worked because you happened to guess the way your compiler
lays out classes. There's absolutely no guarantee, and the
behavior is completely undefined.
Note that the standard makes absolutely no guarantees with
regards to class layout; the compiler can do pretty much
anything it wishes.
Also, even if it worked, it's a lot less maintainable than the C
style cast. The reason you should avoid C style casts (when
pointers or references are involved---otherwise, it depends) is
because there is normally something better to use. If there's
not something better, of course, you shouldn't force the issue
by using something worse. (On the other hand, you might ask
yourself questions as to why you want to do this. If the
inheritance is private, it's probably private for a reason.)
--
James Kanze