Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>One of the "special abilities" of a standard-layout class, is that you can <code>reinterpret_cast</code> a pointer to a standard-layout class object to the type of its first data member, and thus obtain a pointer to the first data member. [Edit: 9.2/19] Further, a standard-layout class with non-static data members is permitted to have empty bases. As you no doubt know, most implementations put base class sub-objects at the start of complete sub-objects. This combination of restrictions effectively <em>mandates</em> that the empty-base-class optimization is applied to all bases of standard-layout classes.</p> <p>However, as other answers have explained, all base class sub-objects and member sub-objects that are part of the same complete object must be distinct, i.e., have different addresses if they are of the same type. Classes which violate your bullet point (that have a base class that is the same type as the first member) can't have the empty-base-class optimization fully applied, and thus can't be standard-layout classes if the base classes are positioned at the start of the complete object.</p> <p>So I'm pretty sure this is what it's getting at - it's trying to say "if a class has base classes, and the empty-base-class optimization can't be applied, then the class is not standard-layout".</p> <p>Edit: I'm being a bit slack with terminology here - it's possible to construct cases where the empty base class optimization can't be fully applied among the base classes (for example, in your <code>struct D</code>), but that doesn't matter because the base classes can still start at the beginning of the object, and conceptually "overlay" the data members, similar to a <code>union</code>. As you say, the base sub-objects get their addresses incremented if they (or a base) would otherwise overlay another base. While it's possible for the same thing to happen to bases of standard-layout cases (if they would overlap a data member of the same type), this would break existing ABIs, and add a special case for little gain.</p> <hr> <p>You're saying that this is "forbidding" a possibility - it's not really forbidding, from my point of view, it's just not granting "standard-layout" status to types that didn't have that originally anyway (classes with bases were not PODs in C++03). So it's not forbidding such types, it's just saying that they don't get the special standard-layout treatment, which they weren't guaranteed in the first place.</p> <hr> <p>Regarding my assertion that non-static data member subobjects and base subobjects are distinct, see if you find this convincing:</p> <ul> <li>5.9/2 (relational operators on pointers) makes it clear that no two data member subobjects (at least, with the same access specifier) have the same address as one another.</li> <li>5.3.1/1 (the unary operator*) says "the expression to which it is applied shall be a pointer to an object type [snip] and the result is an lvalue referring to <em>the</em> object to which the expression points." (emphasis added) This implies that there is at most one object of a given type at a particular address, at a given time.</li> <li>1.8/2 "A subobject can be a member subobject (9.2), a base class subobject (Clause 10), or an array element."... I think this implies that the categories are mutually exclusive (even if their storage overlaps). Other parts of the standard pretty strongly imply that base subobjects and member subobjects are distinct (e.g. 12.6.2).</li> <li>Steve M's citation of 10.1/4 "For each distinct occurrence of a non-virtual base class in the class lattice of the most derived class, the most derived object (1.8) shall contain a corresponding distinct base class subobject of that type." - I believe this means that different bases must be at different addresses, or else they would not be "distinct" objects - there would be no way to distinguish them during their common lifetime.</li> </ul> <p>I don't know how convincing this is, if you don't consider footnotes as normative or sufficiently indicating intention. For what it's worth, Stroustrup explains derived classes in "The C++ Programming Language" 12.2 in terms of member objects that have compiler-supported conversion from derived to base. Indeed, at the very end of this section, he explicitly says: "Using a class as a base is equivalent to declaring an (unnamed) object of that class. Consequently, a class must be defined in order to be used as a base (section 5.7)."</p> <hr> <p>Also: it seems that GCC 4.5 does <em>not</em> bump up the base class in this specific situation, even though it <em>does</em> bump up the bases where you have repeated base classes (as you showed):</p> <pre><code>#include &lt;assert.h&gt; #include &lt;iostream&gt; struct E {}; struct D: E { E x ; }; int main() { D d; std::cerr &lt;&lt; "&amp;d: " &lt;&lt; (void*)(&amp;d) &lt;&lt; "\n"; std::cerr &lt;&lt; "&amp;d.x: " &lt;&lt; (void*)(&amp;(d.x)) &lt;&lt; "\n"; std::cerr &lt;&lt; "(E*)&amp;d: " &lt;&lt; (void*)(E*)(&amp;d) &lt;&lt; "\n"; assert(reinterpret_cast&lt;E *&gt;(&amp;d) == &amp;d.x); //standard-layout requirement } </code></pre> <p>Output (Linux x86-64, GCC 4.5.0): </p> <pre> &d: 0x7fffc76c9420 &d.x: 0x7fffc76c9421 (E*)&d: 0x7fffc76c9420 testLayout: testLayout.cpp:19: int main(): Assertion `reinterpret_cast(&d) == &d.x' failed. Aborted </pre>
    singulars
    1. This table or related slice is empty.
    1. PO"no base classes of the same type as the first non-static data member"
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDoug
    1. USDoug
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO"no base classes of the same type as the first non-static data member"
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThe relevant point is 9.2/19, "A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member…". This is probably what led me to initially say "… must produce two instances…" However, the placement of base classes is implementation-defined, and empty bases can go anywhere as GCC's workaround demonstrates. (http://ideone.com/Zy4qj) If the initial member shares its type with an empty base, GCC can apply the same workaround as for another indirect base of the same type, and bump the base to a higher address.
      singulars
      1. PO
      1. USPotatoswatter
    2. CO@Potatoswatter: Yes, I think bumping up the position of the base class would be a suitable workaround, but it would introduce an ABI special case and backward compatibility breakage in basically every implementation out there. It's possible that the committee thought that the extra hassle wasn't worth it, for one special case.
      singulars
      1. PO
      1. USDoug
    3. CO@Doug: Bumping up the position of the *empty* base class which has no storage. As I noted, GCC already does it that way. (I just updated the ideone link to demonstrate this case too.) How does forbidding something entirely allow more backward compatibility than any other alternative?
      singulars
      1. PO
      1. USPotatoswatter
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload