Title
Declaration order in layout-compatible POD structs
Status
cd1
Section
11.4 [class.mem]
Submitter
Martin Sebor

Created on 2007-03-01.00:00:00 last changed 161 months ago

Messages

Date: 2007-07-15.00:00:00

[Voted into the WP at the July, 2007 meeting as part of paper J16/07-0202 = WG21 N2342.]

Date: 2007-04-15.00:00:00

Proposed resolution (April, 2007):

This issue will be resolved by the adoption of the POD proposal (currently J16/07-0090 = WG21 N2230). That paper does not propose a change to the wording of 9.4.2 [dcl.init.aggr] paragraph 2, but the CWG feels that the intent of that paragraph (that the initializers are used in declaration order) is clear enough not to require revision.

Date: 2020-12-15.00:00:00

It should be made clear in 11.4 [class.mem] paragraph 15,

Two POD-struct (clause Clause 11 [class]) types are layout-compatible if they have the same number of non-static data members, and corresponding non-static data members (in order) have layout-compatible types (6.8 [basic.types]).

that “corresponding... (in order)” refers to declaration order and not the order in which the members are laid out in memory.

However, this raises the point that, in cases where an access-specifier is involved, the declaration and layout order can be different (see paragraph 12). Thus, for two POD-struct classes A and B,

    struct A {
        char c;
        int i;
    }
    struct B {
        char c;
      public:
        int i;
    };

a compiler could move B::i before B::c, but A::c must precede A::i. It does not seem reasonable that these two POD-structs would be considered layout-compatible, even though they satisfy the requirement that corresponding members in declaration order are layout-compatible.

One possibility would be to require that neither POD-struct have an access-specifier in order to be considered layout-compatible. (It's not sufficient to require that they have the same access-specifiers, because the compiler is not required to lay out the storage the same way for different classes.)

9.4.2 [dcl.init.aggr] paragraph 2 should also be clarified to make explicit that “increasing... member order” refers to declaration order.

History
Date User Action Args
2008-10-05 00:00:00adminsetstatus: wp -> cd1
2008-06-29 00:00:00adminsetmessages: + msg1726
2007-12-10 00:00:00adminsetstatus: review -> wp
2007-05-06 00:00:00adminsetmessages: + msg1482
2007-05-06 00:00:00adminsetstatus: open -> review
2007-03-01 00:00:00admincreate