This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[Accepted as a DR at the July, 2019 meeting.]
According to 11.4 [class.mem] paragraph 19,
Non-static data members of a (non-union) class with the same access control (11.8 [class.access]) are allocated so that later members have higher addresses within a class object.
With the advent of the [[no_unique_address]] attribute, “higher addresses” is no longer strictly accurate. According to the FAQ in P0840R2, next-to-last question:
Q: Suppose I have members a, b, c (in that order, with the same access). Today we guarantee that &a < &b < &c. What happens if b has the attribute?
Two cases:
If the type of b is empty, then there is no guarantee about the address of b (other than that it is somewhere within the containing object).
If the type of b is nonempty, then we still guarantee that &a < &b < &c.
Presumably the wording in 11.4 [class.mem] paragraph 19 needs to be changed to reflect that intent.
Proposed resolution, March, 2019:
Change 11.4 [class.mem] paragraph 19 as follows:
[Note: Non-static data members of a (non-union) class with the same access control (11.8 [class.access]) and non-zero size (6.7.2 [intro.object]) 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(11.8 [class.access]). 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 (11.7.3 [class.virtual]) and virtual base classes (11.7.2 [class.mi]). —end note]