This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2023-01-15


2404. [[no_unique_address]] and allocation order

Section: 11.4  [class.mem]     Status: CD5     Submitter: Daveed Vandevoorde     Date: 2018-12-13

[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:

  1. 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).

  2. 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]