[basic.life] - C++17 → C++20

Files changed (1) hide show

tmp/tmpl4efa8et/{from.md → to.md} +73 -77

tmp/tmpl4efa8et/{from.md → to.md} RENAMED Viewed

@@ -1,90 +1,85 @@
-## Object lifetime <a id="basic.life">[[basic.life]]</a>
 The *lifetime* of an object or reference is a runtime property of the
-object or reference. An object is said to have *non-vacuous
-initialization* if it is of a class or aggregate type and it or one of
-its subobjects is initialized by a constructor other than a trivial
-default constructor.
-[*Note 1*: Initialization by a trivial copy/move constructor is
-non-vacuous initialization. — *end note*]
-The lifetime of an object of type `T` begins when:
 - storage with the proper alignment and size for type `T` is obtained,
   and
-- if the object has non-vacuous initialization, its initialization is
- complete,
 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]]. The lifetime of an object *o* of type `T` ends when:
-- if `T` is a class type with a non-trivial destructor (
-  [[class.dtor]]), the destructor call starts, or
 - the storage which the object occupies is released, or is reused by an
-  object that is not nested within *o* ([[intro.object]]).
 The lifetime of a reference begins when its initialization is complete.
-The lifetime of a reference ends as if it were a scalar object.
-[*Note 2*:  [[class.base.init]] describes the lifetime of base and
 member subobjects. — *end note*]
 The properties ascribed to objects and references throughout this
-International Standard apply for a given object or reference only during
-its lifetime.
-[*Note 3*: In particular, before the lifetime of an object starts and
 after its lifetime ends there are significant restrictions on the use of
 the object, as described below, in  [[class.base.init]] and in
 [[class.cdtor]]. Also, the behavior of an object under construction and
 destruction might not be the same as the behavior of an object whose
 lifetime has started and not ended. [[class.base.init]] and
-[[class.cdtor]] describe the behavior of objects during the construction
-and destruction phases. — *end note*]
 A program may end the lifetime of any object by reusing the storage
-which the object occupies or by explicitly calling the destructor for an
-object of a class type with a non-trivial destructor. For an object of a
-class type with a non-trivial destructor, the program is not required to
-call the destructor explicitly before the storage which the object
-occupies is reused or released; however, if there is no explicit call to
-the destructor or if a *delete-expression* ([[expr.delete]]) is not
-used to release the storage, the destructor shall not be implicitly
-called and any program that depends on the side effects produced by the
-destructor has undefined behavior.
 Before the lifetime of an object has started but after the storage which
-the object will occupy has been allocated[^16] or, after the lifetime of
 an object has ended and before the storage which the object occupied is
 reused or released, any pointer that represents the address of the
 storage location where the object will be or was located may be used but
 only in limited ways. For an object under construction or destruction,
 see  [[class.cdtor]]. Otherwise, such a pointer refers to allocated
-storage ([[basic.stc.dynamic.deallocation]]), and using the pointer as
-if the pointer were of type `void*`, is well-defined. Indirection
-through such a pointer is permitted but the resulting lvalue may only be
-used in limited ways, as described below. The program has undefined
-behavior if:
 - the object will be or was of a class type with a non-trivial
   destructor and the pointer is used as the operand of a
   *delete-expression*,
 - the pointer is used to access a non-static data member or call a
   non-static member function of the object, or
-- the pointer is implicitly converted ([[conv.ptr]]) to a pointer to a
   virtual base class, or
-- the pointer is used as the operand of a `static_cast` (
-  [[expr.static.cast]]), except when the conversion is to pointer to
   cv `void`, or to pointer to cv `void` and subsequently to pointer to
-  cv `char`, cv `unsigned char`, or cv `std::byte` ([[cstddef.syn]]),
-  or
-- the pointer is used as the operand of a `dynamic_cast` (
-  [[expr.dynamic.cast]]).
 [*Example 1*:
 ``` cpp
 #include <cstdlib>
@@ -108,11 +103,11 @@ void g() {
   void* p = std::malloc(sizeof(D1) + sizeof(D2));
   B* pb = new (p) D1;
   pb->mutate();
   *pb;              // OK: pb points to valid memory
   void* q = pb;     // OK: pb points to valid memory
-  pb->f();          // undefined behavior, lifetime of *pb has ended
 }
 ```
 — *end example*]
@@ -120,41 +115,42 @@ Similarly, before the lifetime of an object has started but after the
 storage which the object will occupy has been allocated or, after the
 lifetime of an object has ended and before the storage which the object
 occupied is reused or released, any glvalue that refers to the original
 object may be used but only in limited ways. For an object under
 construction or destruction, see  [[class.cdtor]]. Otherwise, such a
-glvalue refers to allocated storage (
-[[basic.stc.dynamic.deallocation]]), and using the properties of the
-glvalue that do not depend on its value is well-defined. The program has
-undefined behavior if:
 - the glvalue is used to access the object, or
 - the glvalue is used to call a non-static member function of the
   object, or
-- the glvalue is bound to a reference to a virtual base class (
-  [[dcl.init.ref]]), or
-- the glvalue is used as the operand of a `dynamic_cast` (
-  [[expr.dynamic.cast]]) or as the operand of `typeid`.
 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 storage for the new object exactly overlays the storage location
- which the original object occupied, and
-- the new object is of the same type as the original object (ignoring
- the top-level cv-qualifiers), and
-- the type of the original object is not const-qualified, and, if a
-  class type, does not contain any non-static data member whose type is
- const-qualified or a reference type, and
-- the original object was a most derived object ([[intro.object]]) of
- type `T` and the new object is a most derived object of type `T` (that
- is, they are not base class subobjects).
 [*Example 2*:
 ``` cpp
 struct C {
@@ -178,18 +174,18 @@ c1 = c2;                        // well-defined
 c1.f();                         // well-defined; c1 refers to a new object of type C
 ```
 — *end example*]
-[*Note 4*: If these conditions are not met, a pointer to the new object
 can be obtained from a pointer that represents the address of its
-storage by calling `std::launder` ([[support.dynamic]]). — *end note*]
-If a program ends the lifetime of an object of type `T` with static (
-[[basic.stc.static]]), thread ([[basic.stc.thread]]), or automatic (
-[[basic.stc.auto]]) storage duration and if `T` has a non-trivial
-destructor,[^17] the program must ensure that an object of the original
 type occupies that same storage location when the implicit destructor
 call takes place; otherwise the behavior of the program is undefined.
 This is true even if the block is exited with an exception.
 [*Example 3*:
@@ -206,14 +202,14 @@ void h() {
 }                               // undefined behavior at block exit
 ```
 — *end example*]
-Creating a new object within the storage that a `const` complete object
 with static, thread, or automatic storage duration occupies, or within
-the storage that such a `const` object used to occupy before its
-lifetime ended, results in undefined behavior.
 [*Example 4*:
 ``` cpp
 struct B {
@@ -229,12 +225,12 @@ void h() {
 }
 ```
 — *end example*]
-In this section, “before” and “after” refer to the “happens before”
-relation ([[intro.multithread]]).
-[*Note 5*: Therefore, undefined behavior results if an object that is
 being constructed in one thread is referenced from another thread
 without adequate synchronization. — *end note*]

+### Lifetime <a id="basic.life">[[basic.life]]</a>
 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]] and [[class.copy.ctor]], and except as described in
+[[allocator.members]]. The lifetime of an object *o* of type `T` ends
+when:
+- if `T` is a non-class type, the object is destroyed, or
+- if `T` is a class type, the destructor call starts, or
 - the storage which the object occupies is released, or is reused by an
+  object that is not nested within *o* [[intro.object]].
 The lifetime of a reference begins when its initialization is complete.
+The lifetime of a reference ends as if it were a scalar object requiring
+storage.
+[*Note 1*:  [[class.base.init]] describes the lifetime of base and
 member subobjects. — *end note*]
 The properties ascribed to objects and references throughout this
+document apply for a given object or reference only during its lifetime.
+[*Note 2*: In particular, before the lifetime of an object starts and
 after its lifetime ends there are significant restrictions on the use of
 the object, as described below, in  [[class.base.init]] and in
 [[class.cdtor]]. Also, the behavior of an object under construction and
 destruction might not be the same as the behavior of an object whose
 lifetime has started and not ended. [[class.base.init]] and
+[[class.cdtor]] describe the behavior of an object during its periods of
+construction and destruction. — *end note*]
 A program may end the lifetime of any object by reusing the storage
+which the object occupies or by explicitly calling a destructor or
+pseudo-destructor [[expr.prim.id.dtor]] for the object. For an object of
+a class type, the program is not required to call the destructor
+explicitly before the storage which the object occupies is reused or
+released; however, if there is no explicit call to the destructor or if
+a *delete-expression* [[expr.delete]] is not used to release the
+storage, the destructor is not implicitly called and any program that
+depends on the side effects produced by the destructor has undefined
+behavior.
 Before the lifetime of an object has started but after the storage which
+the object will occupy has been allocated[^11] or, after the lifetime of
 an object has ended and before the storage which the object occupied is
 reused or released, any pointer that represents the address of the
 storage location where the object will be or was located may be used but
 only in limited ways. For an object under construction or destruction,
 see  [[class.cdtor]]. Otherwise, such a pointer refers to allocated
+storage [[basic.stc.dynamic.allocation]], and using the pointer as if
+the pointer were of type `void*` is well-defined. Indirection through
+such a pointer is permitted but the resulting lvalue may only be used in
+limited ways, as described below. The program has undefined behavior if:
 - the object will be or was of a class type with a non-trivial
   destructor and the pointer is used as the operand of a
   *delete-expression*,
 - the pointer is used to access a non-static data member or call a
   non-static member function of the object, or
+- the pointer is implicitly converted [[conv.ptr]] to a pointer to a
   virtual base class, or
+- the pointer is used as the operand of a `static_cast`
+  [[expr.static.cast]], except when the conversion is to pointer to
   cv `void`, or to pointer to cv `void` and subsequently to pointer to
+  cv `char`, cv `unsigned char`, or cv `std::byte` [[cstddef.syn]], or
+- the pointer is used as the operand of a `dynamic_cast`
+  [[expr.dynamic.cast]].
 [*Example 1*:
 ``` cpp
 #include <cstdlib>
   void* p = std::malloc(sizeof(D1) + sizeof(D2));
   B* pb = new (p) D1;
   pb->mutate();
   *pb;              // OK: pb points to valid memory
   void* q = pb;     // OK: pb points to valid memory
+  pb->f();          // undefined behavior: lifetime of *pb has ended
 }
 ```
 — *end example*]
 storage which the object will occupy has been allocated or, after the
 lifetime of an object has ended and before the storage which the object
 occupied is reused or released, any glvalue that refers to the original
 object may be used but only in limited ways. For an object under
 construction or destruction, see  [[class.cdtor]]. Otherwise, such a
+glvalue refers to allocated storage [[basic.stc.dynamic.allocation]],
+and using the properties of the glvalue that do not depend on its value
+is well-defined. The program has undefined behavior if:
 - the glvalue is used to access the object, or
 - the glvalue is used to call a non-static member function of the
   object, or
+- the glvalue is bound to a reference to a virtual base class
+  [[dcl.init.ref]], or
+- the glvalue is used as the operand of a `dynamic_cast`
+  [[expr.dynamic.cast]] or as the operand of `typeid`.
 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. An
+object o₁ is *transparently replaceable* by an object o₂ if:
+- the storage that o₂ occupies exactly overlays the storage that o₁
+  occupied, and
+- o₁ and o₂ are of the same type (ignoring the top-level cv-qualifiers),
+  and
+- o₁ is not a complete const object, and
+- neither o₁ nor o₂ is a potentially-overlapping subobject
+ [[intro.object]], and
+- either o₁ and o₂ are both complete objects, or o₁ and o₂ are direct
+ subobjects of objects p₁ and p₂, respectively, and p₁ is transparently
+ replaceable by p₂.
 [*Example 2*:
 ``` cpp
 struct C {
 c1.f();                         // well-defined; c1 refers to a new object of type C
 ```
 — *end example*]
+[*Note 3*: If these conditions are not met, a pointer to the new object
 can be obtained from a pointer that represents the address of its
+storage by calling `std::launder` [[ptr.launder]]. — *end note*]
+If a program ends the lifetime of an object of type `T` with static
+[[basic.stc.static]], thread [[basic.stc.thread]], or automatic
+[[basic.stc.auto]] storage duration and if `T` has a non-trivial
+destructor,[^12] the program must ensure that an object of the original
 type occupies that same storage location when the implicit destructor
 call takes place; otherwise the behavior of the program is undefined.
 This is true even if the block is exited with an exception.
 [*Example 3*:
 }                               // undefined behavior at block exit
 ```
 — *end example*]
+Creating a new object within the storage that a const complete object
 with static, thread, or automatic storage duration occupies, or within
+the storage that such a const object used to occupy before its lifetime
+ended, results in undefined behavior.
 [*Example 4*:
 ``` cpp
 struct B {
 }
 ```
 — *end example*]
+In this subclause, “before” and “after” refer to the “happens before”
+relation [[intro.multithread]].
+[*Note 4*: Therefore, undefined behavior results if an object that is
 being constructed in one thread is referenced from another thread
 without adequate synchronization. — *end note*]

Diff to HTML by rtfpessoa