cplusplus / cplusplus/draft

[basic.life] Does storage reuse update pointers/references/names when the original object’s lifetime has not ended?

Open
#4,906 19 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TeX
Stars
221
Forks
813
Avg merge
16h 4m
Merged PRs (30d)
36

Description

[basic.life/8] specifies (bold emphasis of the condition mine):

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if the original object is transparently replaceable (see below) by the new object.

Basically the condition is this: if a new object reuses the storage occupied by an original object whose lifetime has ended, then…

But why isn’t it just this (i.e. removing the condition ‘whose lifetime has ended’): if a new object reuses the storage occupied by an original object, then…

In other words, does the consequence on pointers/references/names referring to the original object still apply with that less strict condition?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with [basic.life/8] in the linked C++ standard draft and compare the current wording with the proposed removal of “whose lifetime has ended.” Determine whether pointer, reference, and name replacement semantics differ when the original lifetime is active; done means resolving the question and identifying any required draft wording change.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
documentation
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.