Does the C++ standard say anything on the address of inherited members? For example if I inherit an int member or a non - virtual method, does it say anything about its address, or a virtual member: if I dont overide it, if I do? The constructor, if I use a previous constructor? Operators, overloaded operators, template members? Does it say anything about these things?
-
1The question is a bit confusing. Most of them are implementation defined. Do you have any code code or a point of what you are trying to achieve ? – Tasos Vogiatzoglou Feb 10 '15 at 17:51
-
1The question marked as duplicate of this question is not really a duplicate. It only addresses the v-table part. It doesn't address other questions raised by the OP - addresses of member variables and non-virtual methods. – R Sahu Feb 10 '15 at 17:55
1 Answers
Standard, section 1.8 is about the C++ object model.
It doesn't say much: the object is a region of memory (but it may contain unused zones for alignment purpose) and can contain subobjects (member subobjects or base class subobjects, or array subobjects). From the definition of a complete object you can infer that subobjects are included in the memory region of their object. And it says that two distinct objects that are neither bitfields nor base class subobjects shall have distinct adresses.
Section 9.2/15 gives some additional information about the order of the addresess within an object :
Nonstatic data members of a (non-union) class with the same access control are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with different access control is unspecified. Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions and virtual base classes.
There are a couple of sentences about unions when all the union members are structs starting with the same sequence of types. Then it is allowed to "inspect the common parts", from which you can deduce that they must have the same address.
Finally, I've found a last one in 9.2/21:
A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa.
And basically, that's it. You see there is a lot of implementation defined stuff here, about the exact layout of each objects.
Unfortunately, you can't even say much about the address of a base class subobject and it's derived object: there could be multiple inheritance as well. So the standard doesn't use address assumptions: it rathers states things like : "If a base class is accessible, one can implicitly convert a pointer to a derived class to a pointer to that base class"

- 68,716
- 7
- 72
- 138
-
Thank you for the answer! For the part about wo distinct objects that are neither bitfeilds or base class subobjects, does this imply that base classes when inherited have a distinct address (as in, it is like a data member internally?)? – The Floating Brain Feb 10 '15 at 18:45
-
1I've just edited to explain the case of relation between base and derived objects. Basically, the compiler knows how to convert the adress of the one to the other (often it is the same address), but you can't make assumptions. If you revert the affirmation "if neither bitfield nor base then must have different address" you obtain "either bitfield or base then it could have same address (but it's not guaranteed). – Christophe Feb 10 '15 at 19:06