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

Files changed (1) hide show

tmp/tmpxc5wnmde/{from.md → to.md} +47 -44

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

@@ -1,24 +1,24 @@
 ### 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]].
@@ -33,43 +33,44 @@ 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`
@@ -101,12 +102,12 @@ void B::mutate() {
 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*]
@@ -141,11 +142,11 @@ 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₂.
@@ -174,21 +175,23 @@ c1 = c2;                        // well-defined
 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*:
 ``` cpp
 class T { };
@@ -202,11 +205,11 @@ 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*:
@@ -228,9 +231,9 @@ void h() {
 — *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*]

 ### 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
+multidimensional) 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]], [[class.copy.ctor]], and [[class.copy.assign]], 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 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 can differ from 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 an object of class type without
+invoking the destructor, by reusing or releasing the storage as
+described above.
+[*Note 3*: A *delete-expression* [[expr.delete]] invokes the destructor
+prior to releasing the storage. — *end note*]
+In this case, the destructor is not implicitly invoked.
+[*Note 4*: The correct behavior of a program often depends on the
+destructor being invoked for each object of class type. — *end note*]
 Before the lifetime of an object has started but after the storage which
+the object will occupy has been allocated[^8]
+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 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`
 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*]
 - 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 const, complete 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₂.
 c1.f();                         // well-defined; c1 refers to a new object of type C
 ```
 — *end example*]
+[*Note 5*: 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,[^9]
+and another object of the original type does not occupy that same
+storage location when the implicit destructor call takes place, the
+behavior of the program is undefined. This is true even if the block is
+exited with an exception.
 [*Example 3*:
 ``` cpp
 class T { };
 }                               // 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*:
 — *end example*]
 In this subclause, “before” and “after” refer to the “happens before”
 relation [[intro.multithread]].
+[*Note 6*: 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