Title
[[no_unique_address]] and allocation order
Status
cd5
Section
11.4 [class.mem]
Submitter
Daveed Vandevoorde

Created on 2018-12-13.00:00:00 last changed 20 months ago

Messages

Date: 2020-12-15.00:00:00

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]
Date: 2019-07-15.00:00:00

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

History
Date User Action Args
2020-12-15 00:00:00adminsetmessages: + msg6405
2018-12-13 00:00:00admincreate