Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[basic.life] Lifetime of union member CWG2675 #3222

Open
RazvanAM opened this issue Sep 11, 2019 · 3 comments
Open

[basic.life] Lifetime of union member CWG2675 #3222

RazvanAM opened this issue Sep 11, 2019 · 3 comments
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.

Comments

@RazvanAM
Copy link

In the latest draft of the C++ standard, [basic.life]/1 states:

The lifetime of an object or reference is a runtime property of the object or reference. A variable is said to have vacuous initialization if it is default-initialized and, if it is of class type or a (possibly multi-dimensional) array thereof, that class type has a trivial default constructor. The lifetime of an object of type T begins when:

  • storage with the proper alignment and size for type T is obtained, and
  • its initialization (if any) is complete (including vacuous initialization) ([dcl.init]),

except that if the object is a union member or subobject thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.union]. [...]

From that paragraph I understand that the only way a member of a union begins its lifetime is:

  • if that member "is the initialized member in the union" (e.g. if it is referenced in a mem-initializer), or
  • some other way mentioned in [class.union]

However, the only normative paragraph in [class.union] that specifies how a union member can begin its lifetime is [class.union]/5 (but it only applies to specific types, i.e. either non-class, non-array, or class type with a trivial constructor that is not deleted, or array of such types).

The next paragraph, [class.union]/6 (comprising a note and an example, therefore it contains no normative text), describes a way to change the active member of a union, by using a placement new-expression, such as new (&u.n) N. However, based on [basic.life]/1, the lifetime of u.n should not start when using the placement new-expression.

If I am not missing anything, I believe that either [basic.life]/1 should be changed or a new paragraph must be added to [class.union].

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Sep 16, 2019
@RazvanAM
Copy link
Author

The highlighted part of [basic.life]/1:

"except that if the object is a union member or subobject thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.union]"

could be interpreted as saying that only the initial object referenced by the union member does not begin its lifetime as specified in the rest of [basic.life]/1.

Therefore if a new object is created in the storage used by the [initial object referenced by the union member] (e.g. using a placement new-expression), this new object does not have to abide to the highlighted part of [basic.life]/1, and its lifetime can begin.

Is this the intended meaning?

@jensmaurer jensmaurer changed the title Lifetime of union member [basic.life] Lifetime of union member Sep 24, 2019
@jensmaurer
Copy link
Member

Editorial teleconference: Send to CWG.

@jensmaurer jensmaurer added cwg Issue must be reviewed by CWG. and removed decision-required A decision of the editorial group (or the Project Editor) is required. labels Sep 30, 2019
@frederick-vs-ja
Copy link
Contributor

CWG2675 addresses this.

@jensmaurer jensmaurer changed the title [basic.life] Lifetime of union member [basic.life] Lifetime of union member CWG2675 Jul 30, 2023
@jensmaurer jensmaurer added the not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking. label Jul 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.
Projects
None yet
Development

No branches or pull requests

3 participants