I was researching how to get the memory offset of a member to a class in C++ and came across this on wikipedia:
In C++ code, you can not use offsetof to access members of structures or classes that are not Plain Old Data Structures.
I tried it out and it seems to work fine.
class Foo
{
private:
int z;
int func() {cout << "this is just filler" << endl; return 0;}
public:
int x;
int y;
Foo* f;
bool returnTrue() { return false; }
};
int main()
{
cout << offsetof(Foo, x) << " " << offsetof(Foo, y) << " " << offsetof(Foo, f);
return 0;
}
I got a few warnings, but it compiled and when run it gave reasonable output:
Laptop:test alex$ ./test
4 8 12
I think I'm either misunderstanding what a POD data structure is or I'm missing some other piece of the puzzle. I don't see what the problem is.
Bluehorn's answer is correct, but for me it doesn't explain the reason for the problem in simplest terms. The way I understand it is as follows:
If NonPOD is a non-POD class, then when you do:
NonPOD np;
np.field;
the compiler does not necessarily access the field by adding some offset to the base pointer and dereferencing. For a POD class, the C++ Standard constrains it to do that(or something equivalent), but for a non-POD class it does not. The compiler might instead read a pointer out of the object, add an offset to that value to give the storage location of the field, and then dereference. This is a common mechanism with virtual inheritance if the field is a member of a virtual base of NonPOD. But it is not restricted to that case. The compiler can do pretty much anything it likes. It could call a hidden compiler-generated virtual member function if it wants.
In the complex cases, it is obviously not possible to represent the location of the field as an integer offset. So offsetof is not valid on non-POD classes.
In cases where your compiler just so happens to store the object in a simple way (such as single inheritance, and normally even non-virtual multiple inheritance, and normally fields defined right in the class that you're referencing the object by as opposed to in some base class), then it will just so happen to work. There are probably cases which just so happen to work on every single compiler there is. This doesn't make it valid.
Appendix: how does virtual inheritance work?
With simple inheritance, if B is derived from A, the usual implementation is that a pointer to B is just a pointer to A, with B's additional data stuck on the end:
A* ---> field of A <--- B*
field of A
field of B
With simple multiple inheritance, you generally assume that B's base classes (call 'em A1 and A2) are arranged in some order peculiar to B. But the same trick with the pointers can't work:
A1* ---> field of A1
field of A1
A2* ---> field of A2
field of A2
A1 and A2 "know" nothing about the fact that they're both base classes of B. So if you cast a B* to A1*, it has to point to the fields of A1, and if you cast it to A2* it has to point to the fields of A2. The pointer conversion operator applies an offset. So you might end up with this:
A1* ---> field of A1 <---- B*
field of A1
A2* ---> field of A2
field of A2
field of B
field of B
Then casting a B* to A1* doesn't change the pointer value, but casting it to A2* adds sizeof(A1) bytes. This is the "other" reason why, in the absence of a virtual destructor, deleting B through a pointer to A2 goes wrong. It doesn't just fail to call the destructor of B and A1, it doesn't even free the right address.
Anyway, B "knows" where all its base classes are, they're always stored at the same offsets. So in this arrangement offsetof would still work. The standard doesn't require implementations to do multiple inheritance this way, but they often do (or something like it). So offsetof might work in this case on your implementation, but it is not guaranteed to.
Now, what about virtual inheritance? Suppose B1 and B2 both have A as a virtual base. This makes them single-inheritance classes, so you might think that the first trick will work again:
A* ---> field of A <--- B1* A* ---> field of A <--- B2*
field of A field of A
field of B1 field of B2
But hang on. What happens when C derives (non-virtually, for simplicity) from both B1 and B2? C must only contain 1 copy of the fields of A. Those fields can't immediately precede the fields of B1, and also immediately precede the fields of B2. We're in trouble.
So what implementations might do instead is:
// an instance of B1 looks like this, and B2 similar
A* ---> field of A
field of A
B1* ---> pointer to A
field of B1
Although I've indicated B1* pointing to the first part of the object after the A subobject, I suspect (without bothering to check) the actual address won't be there, it'll be the start of A. It's just that unlike simple inheritance, the offsets between the actual address in the pointer, and the address I've indicated in the diagram, will never be used unless the compiler is certain of the dynamic type of the object. Instead, it will always go through the meta-information to reach A correctly. So my diagrams will point there, since that offset will always be applied for the uses we're interested in.
The "pointer" to A could be a pointer or an offset, it doesn't really matter. In an instance of B1, created as a B1, it points to (char*)this - sizeof(A), and the same in an instance of B2. But if we create a C, it can look like this:
A* ---> field of A
field of A
B1* ---> pointer to A // points to (char*)(this) - sizeof(A) as before
field of B1
B2* ---> pointer to A // points to (char*)(this) - sizeof(A) - sizeof(B1)
field of B2
C* ----> pointer to A // points to (char*)(this) - sizeof(A) - sizeof(B1) - sizeof(B2)
field of C
field of C
So to access a field of A using a pointer or reference to B2 requires more than just applying an offset. We must read the "pointer to A" field of B2, follow it, and only then apply an offset, because depending what class B2 is a base of, that pointer will have different values. There is no such thing as offsetof(B2,field of A): there can't be. offsetof will never work with virtual inheritance, on any implementation.
Short answer: offsetof is a feature that is only in the C++ standard for legacy C compatibility. Therefore it is basically restricted to the stuff than can be done in C. C++ supports only what it must for C compatibility.
As offsetof is basically a hack (implemented as macro) that relies on the simple memory-model supporting C, it would take a lot of freedom away from C++ compiler implementors how to organize class instance layout.
The effect is that offsetof will often work (depending on source code and compiler used) in C++ even where not backed by the standard - except where it doesn't. So you should be very careful with offsetof usage in C++, especially since I do not know a single compiler that will generate a warning for non-POD use... Modern GCC and Clang will emit a warning if offsetof is used outside the standard (-Winvalid-offsetof).
Edit: As you asked for example, the following might clarify the problem:
#include <iostream>
using namespace std;
struct A { int a; };
struct B : public virtual A { int b; };
struct C : public virtual A { int c; };
struct D : public B, public C { int d; };
#define offset_d(i,f) (long(&(i)->f) - long(i))
#define offset_s(t,f) offset_d((t*)1000, f)
#define dyn(inst,field) {\
cout << "Dynamic offset of " #field " in " #inst ": "; \
cout << offset_d(&i##inst, field) << endl; }
#define stat(type,field) {\
cout << "Static offset of " #field " in " #type ": "; \
cout.flush(); \
cout << offset_s(type, field) << endl; }
int main() {
A iA; B iB; C iC; D iD;
dyn(A, a); dyn(B, a); dyn(C, a); dyn(D, a);
stat(A, a); stat(B, a); stat(C, a); stat(D, a);
return 0;
}
This will crash when trying to locate the field a inside type B statically, while it works when an instance is available. This is because of the virtual inheritance, where the location of the base class is stored into a lookup table.
While this is a contrived example, an implementation could use a lookup table also to find the public, protected and private sections of a class instance. Or make the lookup completely dynamic (use a hash table for fields), etc.
The standard just leaves all possibilities open by restricting offsetof to POD (IOW: no way to use a hash table for POD structs... :)
Just another note: I had to reimplement offsetof (here: offset_s) for this example as GCC actually errors out when I call offsetof for a field of a virtual base class.
In general, when you ask "why is something undefined", the answer is "because the standard says so". Usually, the rational is along one or more reasons like:
it is difficult to detect statically in which case you are.
corner cases are difficult to define and nobody took the pain of defining special cases;
its use is mostly covered by other features;
existing practices at the time of standardization varied and breaking existing implementation and programs depending on them was deemed more harmful that standardization.
Back to offsetof, the second reason is probably a dominant one. If you look at C++0X, where the standard was previously using POD, it is now using "standard layout", "layout compatible", "POD" allowing more refined cases. And offsetof now needs "standard layout" classes, which are the cases where the committee didn't want to force a layout.
You have also to consider the common use of offsetof(), which is to get the value of a field when you have a void* pointer to the object. Multiple inheritance -- virtual or not -- is problematic for that use.
I think your class fits the c++0x definition of a POD. g++ has implemented some of c++0x in their latest releases. I think that VS2008 also has some c++0x bits in it.
From wikipedia's c++0x article
C++0x will relax several rules with regard to the POD definition.
A class/struct is considered a POD if it is trivial, standard-layout, and
if all of its non-static members are
PODs.
A trivial class or struct is defined
as one that:
Has a trivial default constructor. This may use the default
constructor syntax (SomeConstructor()
= default;).
Has a trivial copy constructor, which may use the default syntax.
Has a trivial copy assignment operator, which may use the default
syntax.
Has a trivial destructor, which must not be virtual.
A standard-layout class or struct is
defined as one that:
Has only non-static data members that are of standard-layout type
Has the same access control (public, private, protected) for all
non-static members
Has no virtual functions
Has no virtual base classes
Has only base classes that are of standard-layout type
Has no base classes of the same type as the first defined non-static
member
Either has no base classes with non-static members, or has no
non-static data members in the most
derived class and at most one base
class with non-static members. In
essence, there may be only one class
in this class's hierarchy that has
non-static members.
For the definition of POD data structure,here you go with the explanation [ already posted in another post in Stack Overflow ]
What are POD types in C++?
Now, coming to your code, it is working fine as expected. This is because, you are trying to find the offsetof(), for the public members of your class, which is valid.
Please let me know, the correct question, if my viewpoint above, doesnot clarify your doubt.
This works every time and its the most portable version to be used in both c and c++
#define offset_start(s) s
#define offset_end(e) e
#define relative_offset(obj, start, end) ((int64_t)&obj->offset_end(end)-(int64_t)&obj->offset_start(start))
struct Test {
int a;
double b;
Test* c;
long d;
}
int main() {
Test t;
cout << "a " << relative_offset((&t), a, a) << endl;
cout << "b " << relative_offset((&t), a, b) << endl;
cout << "c " << relative_offset((&t), a, c) << endl;
cout << "d " << relative_offset((&t), a, d) << endl;
return 0;
}
The above code simply requires you to hold an instance of some object be it a struct or a class. you then need to pass a pointer reference to the class or struct to gain access to its fields. To make sure you get the right offset never set the "start" field to be under the "end" field. We use the compiler to figure out what the address offset is at run-time.
This allows you to not have to worry about the problems with compiler padding data, etc.
If you add, for instance, a virtual empty destructor:
virtual ~Foo() {}
Your class will become "polymorphic", i.e. it will have a hidden member field which is a pointer to a "vtable" that contains pointers to virtual functions.
Due to the hidden member field, the size of an object, and offset of members, will not be trivial. Thus, you should get trouble using offsetof.
I bet you compile this with VC++. Now try it with g++, and see how it works...
Long story short, it's undefined, but some compilers may allow it. Others do not. In any case, it's non-portable.
Works for me
#define get_offset(type, member) ((size_t)(&((type*)(1))->member)-1)
#define get_container(ptr, type, member) ((type *)((char *)(ptr) - get_offset(type, member)))
In C++ you can get the relative offset like this:
class A {
public:
int i;
};
class B : public A {
public:
int i;
};
void test()
{
printf("%p, %p\n", &A::i, &B::i); // edit: changed %x to %p
}
This seems to work fine for me:
#define myOffset(Class,Member) ({Class o; (size_t)&(o.Member) - (size_t)&o;})
Related
We have a multiple inheritance hierarchy:
// A B
// \ /
// C
//
Both A and B are abstract classes. C is actually a templated class, so downcasting is near impossible if you have a B and you want to access a member of it as an A.
All A's and B's must be C's, since that is the only concrete class in the hierarchy. Therefore, all A's must be B's, and vice versa.
I'm trying to debug something quickly where I have a B that I need to access A::name of. I can't downcast to C because I don't know the templated type of it. So I'm writing code like below and surprisingly it doesn't work; and I'm wondering what gives.
struct A { virtual void go() = 0; std::string name; };
struct B { virtual void go() = 0; };
struct C : A, B { void go() override { } };
int main()
{
C c;
c.name = "Pointer wonders";
puts(c.name.c_str()); // Fine.
B* b = (B*)&c;
//puts(b->name.c_str()); // X no from compiler.
A* a1 = (A*)&c;
puts(a1->name.c_str()); // As expected this is absolutely fine
// "Cross" the hierarchy, because the B really must be a __C__, because of the purely virtual functions.
// neither A nor B can be instantiated, so every instance of A or B must really be a C.
A* a2 = (A*)b;
puts(a2->name.c_str()); // Why not??
// If you downcast first, it works
C* c2 = (C*)b;
A* a3 = (A*)c2;
puts(a3->name.c_str()); // fine
}
First of all, stop using C style cast. The compiler won't complain if you do something wrong (C style cast usually do not works in multiple inheritance).
Any cast that cause run-time error in you example would not compile with a static_cast. While it is a bit longer to type, you get instant feedback when used improperly instead of undefined behavior that will sometime corrupt data and cause problem long afterward when that data is use.
As A and B contains virtual function, you can easily use dynamic_cast without knowing C. If you know C, you could use static_cast to C if you know there is a derived C for sure. But why not use virtual functions and not do any crossing between siblings?
The reason it does not works is because C-style cast can do any of the following cast:
static_cast
reinterperet_cast
const_cast
Also, C style cast will do a reinterpret_cast if the definition of a class is missing. You also need to be very careful with void *as you must convert back to original type.
As a simplified rule, you can imagine that C cast is like doing either a single static_cast (known child or parent class or primitive types like int) or reinterpret_cast (unknown type, not a parent/child class) followed by a const_cast if necessary.
C * --> void * --> B * won't work with any C or C++ cast.
Th primary reason that such cast don't works is that the compiler must adjust this pointer when doing a cast and multiple inheritance is used. This is required to take into account that the A and B part start at a distinct offset.
Alternatively, you can add a virtual function A * GetA() = 0 in B and implemente it in C to have your own way to navigate. That can be an option if is unknown and RTTI must be disabled (for ex. on embedded systems).
Honestly, you should avoid multiple inheritance and casting as it make the code harder to maintain as it increase coupling between classes and it can cause hard to find bug particularily when mixing both together.
I've been using multiple inheritance in c++ for quite a long time, but only realised today that this could imply that the pointer addresses could be different when referencing them as one of the subclasses.
For example, if I have:
class ClassA{
public:
int x;
int y;
ClassA(){
cout << "ClassA : " << (unsigned int)this << endl;
}
};
class ClassC{
public:
int cc;
int xx;
ClassC(){
cout << "ClassC : " << (unsigned int)this << endl;
}
};
class ClassB : public ClassC, public ClassA{
public:
int z;
int v;
ClassB(){
cout << "ClassB : " << (unsigned int)this << endl;
}
};
int main(){
ClassB * b = new ClassB();
}
class A and class C have different addresses when printed on the constructor.
Yet, when I try to cast them back to each other, it just works automagically:
ClassA * the_a = (ClassA*)b;
cout << "The A, casted : " << (unsigned int)the_a << endl;
ClassB * the_b = (ClassB*)the_a;
cout << "The B, casted back : " << (unsigned int)the_b << endl;
I suppose this kind of information can be derived by the compiler from the code, but is it safe to assume that this works on all compilers?
Additional Question : is it possible to force the order in which the subclass locations go? For example, if I need classA to be located first (essentially, share the same pointer location) as ClassC which subclasses it, do I just need to put it first in the declaration of subclasses?
Update Okay, looks like it's not possible to force the order. Is it still possible to find out the "root" address of the structure, the start of the address allocated to the subclass, at the superclass level? For example, getting classB's address from ClassA.
That's a perfectly standard use of multiple inheritance, and it will work on any compliant compiler. You should however note that an explicit cast in unnecessary in the first case, and that the 'C style cast' could be replaced by a static_cast in the second.
Is it possible to force the order in which the subclass locations go.
No : the layout is implementation defined, and your code should not depend on this ordering.
Yes, you can ssume that this is safe. A pointer typecast in C++ is guaranteed to correctly adjust the pointer to account for base-to-derived or vice-versa conversions.
That said, you have to be careful not to push the system too far. For example, the compiler won't get this conversion right:
ClassB* b = new ClassB;
ClassC* c = (ClassC*)(void*)b;
This breaks because the cast from C to A get funneled through a void*, and so the information about where the pointer is inside the B object is lost.
Another case where a straight cast won't work is with virtual inheritance. If you want to cast from a derived class to a virtual base or vice-versa, I believe you have to use the dynamic_cast operator to ensure that the cast succeeds.
Yea, a naive implementation for virtual bases is to place at a known location in the derived object a pointer to the virtual base subobject.
If you have multiple virtual bases that's a bit expensive. A better representation (patented by Microsoft I think) uses self-relative offsets. Since these are invariant for each subobject (that is, they don't depend on the object address), they can be stored once in static memory, and all you need is a single pointer to them in each subobject.
Without some such data structure, cross casts would not work. You can cross cast from a virtual base A to a virtual base B inside the virtual base A even though B subobject isn't visible (provided only the two bases have a shared virtual base X if I recall correctly). That's pretty hairy navigation when you think about it: the navigation goes via the shape descriptor of the most derived class (which can see both A and B).
What's even more hairy is that the structure so represented is required "by law of the Standard" to change dynamically during construction and destruction, which is why construction and destruction of complex objects is slow. Once they're made, however, method calls, even cross calls, are quite fast.
Say you have these two types:
struct alignas(8) Base { double a; double b; }
struct alignas(16) Derived : public Base {}
And these functions:
void Foo(Base b)
void Bar(Base* start, Base* end)
Is it legal to make calls like
Foo(someDerived)
Bar(someDerivedArray, someDerivedArray + arrayLength)
in all cases? Does it depend on the contents of Base and the specific alignment restrictions? I could absolutely see there being an issue if derived were, say, 32-bit aligned, because then there'd be a gap in-between elements of someDerivedArray and Bar wouldn't know about that gap, so I assume this is undefined behaviour, but I'm not sure.
XY explanation: we're using the GPGPU library Thrust and its complex type has inconsistent alignments between device code and host code; we're trying to figure out how to work around the issue. One option is to define our own complex type deriving from thrust::complex but with the same alignment specifier and use that, but of course various thrust functions expect a thrust::complex, so we'd be slicing into or casting into the less-aligned type.
Doing pointer arithmetic on a Base*, if the pointer actually points to a Derived object, it always UB. Alignment is irrelevant. If Base and Derived have the same size then this might appear to work, but it is still UB.
Passing a pointer to a Derived object to a function that takes Base*, and does not perform pointer arithmetic, is usually fine, with the caveat that if the function will be performing delete on the pointer, then Base must have a virtual destructor. Again, alignment is not relevant.
The reason why increasing the alignment of Derived makes no difference is that the Base subobject of it is still forced to be aligned according to the alignment of Base. (This is why, in general, you can increase the alignment of a derived class relative to the base class, but not decrease.) So when the Derived* is converted to a Base*, you still get a valid pointer value: it points to a Base object and that object is correctly aligned. (In fact, there is no such thing as an object that is not properly aligned for its type. Any attempt to create such an object would cause UB.)
So Foo(someDerived) will usually be fine as long as Foo doesn't attempt to delete the pointer, whereas Bar(someDerivedArray, someDerivedArray + arrayLength) will not.
alignas applies only to Base and Derived;
They do not apply to their members: a and b.
So there are no issues.
#include <iostream>
using namespace std;
struct A
{
int x, y, z, w;
};
struct alignas(64) B
{
alignas(64) int x;
alignas(64) float y, z, w;
};
struct alignas(64) C : public A
{
};
int main()
{
A a;
B b;
C c;
cout << size_t((char*)(void*)&(a.y)-(char*)(void*)&(a.x)) << endl;
cout << size_t((char*)(void*)&(b.y)-(char*)(void*)&(b.x)) << endl;
cout << size_t((char*)(void*)&(c.y)-(char*)(void*)&(c.x)) << endl;
return 0;
}
It returns
4
64
4
Edit: if you don't believe me, run the code yourself. I am not sure why would anyone think that alignas would enforce alignment to each member of the class.
The definition of alignas states that it applies to the class itself (only that the alignment of the class is affected by alignment of its members and not members affected by the class).
Edit 2: with regards to Thrust - if device and host decide on different alignments in classes then it is an error of consistency of different compilers that need to be in sync. You can file the bug to NVIDIA as it is their problem.
How to workaround such problems? That's a complicated question... good luck.
Suppose the following code with basic structures
struct A {int aMember};
struct B {bool bMember};
struct C {double cMember};
struct BA : B, A {};
struct CB : C, B {} ;
void test(B *base) {
bool retrieved = base->bMember;
}
Here the test function is able to be passed a pointer to an instance of B, BA, or CB. How is the retrieval of the base class member "bMember" achieved in low-level terms? Presumably the member can't be guaranteed to be located at a given offset from the passed objects addressee for every derived type. In short, how is it "known" where the slice of B's members are located for any given derived type? Is this achieved at run-time with some sort of meta-data associated with objects and classes utilizing inheritance?
I'm terribly sorry if there's a simple explanation already posted. I just didn't know how to phrase my search to return a relevant answer.
Thankyou!
test must be called with an argument of type B*. The compiler knows that even if it can't see the definition of test because C++ requires a function to be declared in any translation unit which references it.
C++ allows you to call test with a pointer to a CB precisely because it knows how to convert a CB* to a B*.
If the structures do not have virtual members, the conversion is normally extremely simple. The CB object will contain a B object at some offset. To convert a CB* to a B*, it is only necessary to add this offset. test doesn't need to know that the argument was converted, and it does not even need to know that CB even exists.
If there are virtual functions, things are slightly more complicated. In principle, the compiler still adjusts the CB* in the same way, but that is not sufficient to find the correct virtual functions at run time.
Although there are various ways to implement virtual functions and the C++ standard does not specify or even recommend a solution, the basic strategy is to include a pointer to a "vtable" in the object with virtual functions. The vtable is an sequence of function pointers for the virtual functions implemented by the actual object. Thus, the B object inside the CB object would have a vtable pointer to the virtual functions defined by CB. These functions must be called with this pointing to the actual CB object, so the vtable or the B object must also contain enough information to derive the CB" from the B*at runtime. One possible solution is to store the adjustment (which will be subtracted from the B*), but there are a variety of other possibilities, with different advantages and disadvantages.
A given member of B is always at the same offset from base, because base is a B*.
The piece of the puzzle I think you're missing is that test isn't passed the address of the object itself when you're passing a BA* or a CB*.
Instead, it's passed the address of their respective subobjects of type B.
Example using your classes:
void test(B *base) {
std::cout << "test got " << base << std::endl;
}
int main()
{
BA ba;
CB cb;
std::cout << "&ba: " << &ba << std::endl;
std::cout << "ba's B subobject: " << static_cast<B*>(&ba) << std::endl;
test(&ba);
std::cout << "&cb: " << &cb << std::endl;
std::cout << "cb's B subobject: " << static_cast<B*>(&cb) << std::endl;
test(&cb);
}
For me, this printed
&ba: 0x28cc78
ba's B subobject: 0x28cc78
test got 0x28cc78
&cb: 0x28cc68
cb's B subobject: 0x28cc70
test got 0x28cc70
Both calls to test pass the B subobject to the function, and every B object looks the same, so test doesn't need to care about the other classes at all.
Note that ba and ba's B subobject are in the same place; this particular implementation arranges subobject in the order they're specified in the inheritance list, and the first one is located first in the derived object.
(This isn't mandated by the standard, but it's a very common layout.)
The standard doesn't define it.
The actual memory layout usually depends on the chosen ABI.
As an example, one of them is the Itanium ABI.
From the introduction:
Application Binary Interface for C++ programs, that is, the object code interfaces between user C++ code and the implementation-provided system and libraries.
This includes the memory layout for C++ data objects, including both predefined and user-defined data types, as well as internal compiler generated objects such as virtual tables. It also includes function calling interfaces, exception handling interfaces, global naming, and various object code conventions.
Here is the section that rules on memory layout.
I've been using multiple inheritance in c++ for quite a long time, but only realised today that this could imply that the pointer addresses could be different when referencing them as one of the subclasses.
For example, if I have:
class ClassA{
public:
int x;
int y;
ClassA(){
cout << "ClassA : " << (unsigned int)this << endl;
}
};
class ClassC{
public:
int cc;
int xx;
ClassC(){
cout << "ClassC : " << (unsigned int)this << endl;
}
};
class ClassB : public ClassC, public ClassA{
public:
int z;
int v;
ClassB(){
cout << "ClassB : " << (unsigned int)this << endl;
}
};
int main(){
ClassB * b = new ClassB();
}
class A and class C have different addresses when printed on the constructor.
Yet, when I try to cast them back to each other, it just works automagically:
ClassA * the_a = (ClassA*)b;
cout << "The A, casted : " << (unsigned int)the_a << endl;
ClassB * the_b = (ClassB*)the_a;
cout << "The B, casted back : " << (unsigned int)the_b << endl;
I suppose this kind of information can be derived by the compiler from the code, but is it safe to assume that this works on all compilers?
Additional Question : is it possible to force the order in which the subclass locations go? For example, if I need classA to be located first (essentially, share the same pointer location) as ClassC which subclasses it, do I just need to put it first in the declaration of subclasses?
Update Okay, looks like it's not possible to force the order. Is it still possible to find out the "root" address of the structure, the start of the address allocated to the subclass, at the superclass level? For example, getting classB's address from ClassA.
That's a perfectly standard use of multiple inheritance, and it will work on any compliant compiler. You should however note that an explicit cast in unnecessary in the first case, and that the 'C style cast' could be replaced by a static_cast in the second.
Is it possible to force the order in which the subclass locations go.
No : the layout is implementation defined, and your code should not depend on this ordering.
Yes, you can ssume that this is safe. A pointer typecast in C++ is guaranteed to correctly adjust the pointer to account for base-to-derived or vice-versa conversions.
That said, you have to be careful not to push the system too far. For example, the compiler won't get this conversion right:
ClassB* b = new ClassB;
ClassC* c = (ClassC*)(void*)b;
This breaks because the cast from C to A get funneled through a void*, and so the information about where the pointer is inside the B object is lost.
Another case where a straight cast won't work is with virtual inheritance. If you want to cast from a derived class to a virtual base or vice-versa, I believe you have to use the dynamic_cast operator to ensure that the cast succeeds.
Yea, a naive implementation for virtual bases is to place at a known location in the derived object a pointer to the virtual base subobject.
If you have multiple virtual bases that's a bit expensive. A better representation (patented by Microsoft I think) uses self-relative offsets. Since these are invariant for each subobject (that is, they don't depend on the object address), they can be stored once in static memory, and all you need is a single pointer to them in each subobject.
Without some such data structure, cross casts would not work. You can cross cast from a virtual base A to a virtual base B inside the virtual base A even though B subobject isn't visible (provided only the two bases have a shared virtual base X if I recall correctly). That's pretty hairy navigation when you think about it: the navigation goes via the shape descriptor of the most derived class (which can see both A and B).
What's even more hairy is that the structure so represented is required "by law of the Standard" to change dynamically during construction and destruction, which is why construction and destruction of complex objects is slow. Once they're made, however, method calls, even cross calls, are quite fast.