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

Files changed (1) hide show

tmp/tmpfjnlpqxv/{from.md → to.md} +226 -268

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

@@ -1,24 +1,29 @@
 ## Memory and objects <a id="basic.memobj">[[basic.memobj]]</a>
 ### Memory model <a id="intro.memory">[[intro.memory]]</a>
 The fundamental storage unit in the C++ memory model is the *byte*. A
-byte is at least large enough to contain any member of the basic
-execution character set [[lex.charset]] and the eight-bit code units of
-the Unicode UTF-8 encoding form and is composed of a contiguous sequence
-of bits,[^9] the number of which is *implementation-defined*. The least
-significant bit is called the *low-order bit*; the most significant bit
-is called the *high-order bit*. The memory available to a C++ program
-consists of one or more sequences of contiguous bytes. Every byte has a
-unique address.
 [*Note 1*: The representation of types is described in
-[[basic.types]]. — *end note*]
-A *memory location* is either an object of scalar type or a maximal
-sequence of adjacent bit-fields all having nonzero width.
 [*Note 2*: Various features of the language, such as references and
 virtual functions, might involve additional memory locations that are
 not accessible to programs but are managed by the
 implementation. — *end note*]
@@ -46,11 +51,11 @@ struct {
   int b:5,
   c:11,
   :0,
   d:8;
   struct {int ee:8;} e;
-}
 ```
 contains four separate memory locations: The member `a` and bit-fields
 `d` and `e.ee` are each separate memory locations, and can be modified
 concurrently without interfering with each other. The bit-fields `b` and
@@ -65,27 +70,27 @@ can be.
 The constructs in a C++ program create, destroy, refer to, access, and
 manipulate objects. An *object* is created by a definition
 [[basic.def]], by a *new-expression* [[expr.new]], by an operation that
 implicitly creates objects (see below), when implicitly changing the
 active member of a union [[class.union]], or when a temporary object is
-created ([[conv.rval]], [[class.temporary]]). An object occupies a
-region of storage in its period of construction [[class.cdtor]],
-throughout its lifetime [[basic.life]], and in its period of destruction
 [[class.cdtor]].
 [*Note 1*: A function is not an object, regardless of whether or not it
 occupies storage in the way that objects do. — *end note*]
 The properties of an object are determined when the object is created.
 An object can have a name [[basic.pre]]. An object has a storage
 duration [[basic.stc]] which influences its lifetime [[basic.life]]. An
-object has a type [[basic.types]]. Some objects are polymorphic
-[[class.virtual]]; the implementation generates information associated
-with each such object that makes it possible to determine that object’s
-type during program execution. For other objects, the interpretation of
-the values found therein is determined by the type of the *expression*s
-[[expr.compound]] used to access them.
 Objects can contain other objects, called *subobjects*. A subobject can
 be a *member subobject* [[class.mem]], a *base class subobject*
 [[class.derived]], or an array element. An object that is not a
 subobject of any other object is called a *complete object*. If an
@@ -103,13 +108,14 @@ another object *e* of type “array of N `unsigned char`” or of type
 “array of N `std::byte`” [[cstddef.syn]], that array *provides storage*
 for the created object if:
 - the lifetime of *e* has begun and not ended, and
 - the storage for the new object fits entirely within *e*, and
-- there is no smaller array object that satisfies these constraints.
-[*Note 2*: If that portion of the array previously provided storage for
 another object, the lifetime of that object ends because its storage was
 reused [[basic.life]]. — *end note*]
 [*Example 1*:
@@ -150,12 +156,12 @@ of* `x`, determined as follows:
 - If `x` is a complete object, then the complete object of `x` is
   itself.
 - Otherwise, the complete object of `x` is the complete object of the
   (unique) object that contains `x`.
-If a complete object, a data member [[class.mem]], or an array element
-is of class type, its type is considered the *most derived class*, to
 distinguish it from the class type of any base class subobject; an
 object of a most derived class type or of a non-class type is called a
 *most derived object*.
 A *potentially-overlapping subobject* is either:
@@ -168,27 +174,28 @@ An object has nonzero size if it
 - is not a potentially-overlapping subobject, or
 - is not of class type, or
 - is of a class type with virtual member functions or virtual base
   classes, or
-- has subobjects of nonzero size or bit-fields of nonzero length.
 Otherwise, if the object is a base class subobject of a standard-layout
 class type with no non-static data members, it has zero size. Otherwise,
 the circumstances under which the object has zero size are
 *implementation-defined*. Unless it is a bit-field [[class.bit]], an
 object with nonzero size shall occupy one or more bytes of storage,
 including every byte that is occupied in full or in part by any of its
 subobjects. An object of trivially copyable or standard-layout type
-[[basic.types]] shall occupy contiguous bytes of storage.
 Unless an object is a bit-field or a subobject of zero size, the address
 of that object is the address of the first byte it occupies. Two objects
 with overlapping lifetimes that are not bit-fields may have the same
 address if one is nested within the other, or if at least one is a
 subobject of zero size and they are of different types; otherwise, they
-have distinct addresses and occupy disjoint bytes of storage.[^10]
 [*Example 2*:
 ``` cpp
 static const char test1 = 'x';
@@ -204,18 +211,18 @@ subobject.
 Some operations are described as *implicitly creating objects* within a
 specified region of storage. For each operation that is specified as
 implicitly creating objects, that operation implicitly creates and
 starts the lifetime of zero or more objects of implicit-lifetime types
-[[basic.types]] in its specified region of storage if doing so would
-result in the program having defined behavior. If no such set of objects
-would give the program defined behavior, the behavior of the program is
-undefined. If multiple such sets of objects would give the program
-defined behavior, it is unspecified which such set of objects is
 created.
-[*Note 3*: Such operations do not start the lifetimes of subobjects of
 such objects that are not themselves of implicit-lifetime
 types. — *end note*]
 Further, after implicitly creating objects within a specified region of
 storage, some operations are described as producing a pointer to a
@@ -246,44 +253,44 @@ X *make_x() {
 }
 ```
 — *end example*]
-An operation that begins the lifetime of an array of `char`,
-`unsigned char`, or `std::byte` implicitly creates objects within the
-region of storage occupied by the array.
-[*Note 4*: The array object provides storage for these
 objects. — *end note*]
 Any implicit or explicit invocation of a function named `operator new`
 or `operator new[]` implicitly creates objects in the returned region of
 storage and returns a pointer to a suitable created object.
-[*Note 5*: Some functions in the C++ standard library implicitly create
-objects ([[allocator.traits.members]], [[c.malloc]], [[cstring.syn]],
-[[bit.cast]]). — *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]].
@@ -298,43 +305,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`
@@ -366,12 +374,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*]
@@ -406,11 +414,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₂.
@@ -439,21 +447,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 { };
@@ -467,11 +477,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*:
@@ -493,11 +503,11 @@ 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*]
 ### Indeterminate values <a id="basic.indet">[[basic.indet]]</a>
@@ -516,13 +526,13 @@ undefined except in the following cases:
   [[basic.fundamental]] or `std::byte` type [[cstddef.syn]] is produced
   by the evaluation of:
   - the second or third operand of a conditional expression
     [[expr.cond]],
   - the right operand of a comma expression [[expr.comma]],
-  - the operand of a cast or conversion ([[conv.integral]],
-    [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]]) to an
-    unsigned ordinary character type or `std::byte` type
     [[cstddef.syn]], or
   - a discarded-value expression [[expr.context]],
   then the result of the operation is an indeterminate value.
 - If an indeterminate value of unsigned ordinary character type or
@@ -553,10 +563,12 @@ int f(bool b) {
 — *end example*]
 ### Storage duration <a id="basic.stc">[[basic.stc]]</a>
 The *storage duration* is the property of an object that defines the
 minimum potential lifetime of the storage containing the object. The
 storage duration is determined by the construct used to create the
 object and is one of the following:
@@ -576,33 +588,35 @@ When the end of the duration of a region of storage is reached, the
 values of all pointers representing the address of any part of that
 region of storage become invalid pointer values [[basic.compound]].
 Indirection through an invalid pointer value and passing an invalid
 pointer value to a deallocation function have undefined behavior. Any
 other use of an invalid pointer value has *implementation-defined*
-behavior.[^13]
 #### Static storage duration <a id="basic.stc.static">[[basic.stc.static]]</a>
-All variables which do not have dynamic storage duration, do not have
-thread storage duration, and are not local have *static storage
-duration*. The storage for these entities lasts for the duration of the
-program ([[basic.start.static]], [[basic.start.term]]).
 If a variable with static storage duration has initialization or a
 destructor with side effects, it shall not be eliminated even if it
 appears to be unused, except that a class object or its copy/move may be
 eliminated as specified in  [[class.copy.elision]].
-The keyword `static` can be used to declare a local variable with static
-storage duration.
-[*Note 1*:  [[stmt.dcl]] describes the initialization of local `static`
-variables; [[basic.start.term]] describes the destruction of local
-`static` variables. — *end note*]
-The keyword `static` applied to a class data member in a class
-definition gives the data member static storage duration.
 #### Thread storage duration <a id="basic.stc.thread">[[basic.stc.thread]]</a>
 All variables declared with the `thread_local` keyword have
 *thread storage duration*. The storage for these entities lasts for the
@@ -615,13 +629,14 @@ specified in  [[basic.start.static]], [[basic.start.dynamic]], and
 [[stmt.dcl]] and, if constructed, is destroyed on thread exit
 [[basic.start.term]]. — *end note*]
 #### Automatic storage duration <a id="basic.stc.auto">[[basic.stc.auto]]</a>
-Block-scope variables not explicitly declared `static`, `thread_local`,
-or `extern` have *automatic storage duration*. The storage for these
-entities lasts until the block in which they are created exits.
 [*Note 1*: These variables are initialized and destroyed as described
 in  [[stmt.dcl]]. — *end note*]
 If a variable with automatic storage duration has initialization or a
@@ -630,30 +645,33 @@ before the end of its block nor eliminate it as an optimization, even if
 it appears to be unused, except that a class object or its copy/move may
 be eliminated as specified in  [[class.copy.elision]].
 #### Dynamic storage duration <a id="basic.stc.dynamic">[[basic.stc.dynamic]]</a>
 Objects can be created dynamically during program execution
 [[intro.execution]], using *new-expression*s [[expr.new]], and destroyed
 using *delete-expression*s [[expr.delete]]. A C++ implementation
 provides access to, and management of, dynamic storage via the global
-*allocation functions* `operator new` and `operator
-new[]` and the global *deallocation functions* `operator
-delete` and `operator delete[]`.
 [*Note 1*: The non-allocating forms described in
 [[new.delete.placement]] do not perform allocation or
 deallocation. — *end note*]
 The library provides default definitions for the global allocation and
 deallocation functions. Some global allocation and deallocation
-functions are replaceable [[new.delete]]. A C++ program shall provide at
-most one definition of a replaceable allocation or deallocation
-function. Any such function definition replaces the default version
-provided in the library [[replacement.functions]]. The following
-allocation and deallocation functions [[support.dynamic]] are implicitly
-declared in global scope in each translation unit of a program.
 ``` cpp
 [[nodiscard]] void* operator new(std::size_t);
 [[nodiscard]] void* operator new(std::size_t, std::align_val_t);
@@ -669,22 +687,24 @@ void operator delete[](void*) noexcept;
 void operator delete[](void*, std::size_t) noexcept;
 void operator delete[](void*, std::align_val_t) noexcept;
 void operator delete[](void*, std::size_t, std::align_val_t) noexcept;
 ```
-These implicit declarations introduce only the function names `operator`
-`new`, `operator` `new[]`, `operator` `delete`, and `operator`
-`delete[]`.
 [*Note 2*: The implicit declarations do not introduce the names `std`,
 `std::size_t`, `std::align_val_t`, or any other names that the library
 uses to declare these names. Thus, a *new-expression*,
 *delete-expression*, or function call that refers to one of these
-functions without importing or including the header `<new>` is
-well-formed. However, referring to `std` or `std::size_t` or
-`std::align_val_t` is ill-formed unless the name has been declared by
-importing or including the appropriate header. — *end note*]
 Allocation and/or deallocation functions may also be declared and
 defined for any class [[class.free]].
 If the behavior of an allocation or deallocation function does not
@@ -692,22 +712,21 @@ satisfy the semantic constraints specified in
 [[basic.stc.dynamic.allocation]] and
 [[basic.stc.dynamic.deallocation]], the behavior is undefined.
 ##### Allocation functions <a id="basic.stc.dynamic.allocation">[[basic.stc.dynamic.allocation]]</a>
-An allocation function shall be a class member function or a global
-function; a program is ill-formed if an allocation function is declared
-in a namespace scope other than global scope or declared static in
-global scope. The return type shall be `void*`. The first parameter
-shall have type `std::size_t` [[support.types]]. The first parameter
-shall not have an associated default argument [[dcl.fct.default]]. The
-value of the first parameter is interpreted as the requested size of the
-allocation. An allocation function can be a function template. Such a
-template shall declare its return type and first parameter as specified
-above (that is, template parameter types shall not be used in the return
-type and first parameter type). Template allocation functions shall have
-two or more parameters.
 An allocation function attempts to allocate the requested amount of
 storage. If it is successful, it returns the address of the start of a
 block of storage whose length in bytes is at least as large as the
 requested size. The order, contiguity, and initial value of storage
@@ -719,11 +738,11 @@ from any previously returned value `p1`, unless that value `p1` was
 subsequently passed to a replaceable deallocation function. Furthermore,
 for the library allocation functions in  [[new.delete.single]] and
 [[new.delete.array]], `p0` represents the address of a block of storage
 disjoint from the storage for any other object accessible to the caller.
 The effect of indirecting through a pointer returned from a request for
-zero size is undefined.[^14]
 For an allocation function other than a reserved placement allocation
 function [[new.delete.placement]], the pointer returned on a successful
 call shall represent the address of storage that is aligned as follows:
@@ -763,14 +782,12 @@ duration [[basic.stc.thread]], for objects of type `std::type_info`
 [[expr.typeid]], or for an exception object
 [[except.throw]]. — *end note*]
 ##### Deallocation functions <a id="basic.stc.dynamic.deallocation">[[basic.stc.dynamic.deallocation]]</a>
-Deallocation functions shall be class member functions or global
-functions; a program is ill-formed if deallocation functions are
-declared in a namespace scope other than global scope or declared static
-in global scope.
 A deallocation function is a *destroying operator delete* if it has at
 least two parameters and its second parameter is of type
 `std::destroying_delete_t`. A destroying operator delete shall be a
 class member function named `operator delete`.
@@ -784,11 +801,11 @@ first parameter shall be `C*`; otherwise, the type of its first
 parameter shall be `void*`. A deallocation function may have more than
 one parameter. A *usual deallocation function* is a deallocation
 function whose parameters after the first are
 - optionally, a parameter of type `std::destroying_delete_t`, then
-- optionally, a parameter of type `std::size_t` [^15], then
 - optionally, a parameter of type `std::align_val_t`.
 A destroying operator delete shall be a usual deallocation function. A
 deallocation function may be an instance of a function template. Neither
 the first parameter nor the return type shall depend on a template
@@ -805,95 +822,30 @@ has no effect.
 If the argument given to a deallocation function in the standard library
 is a pointer that is not the null pointer value [[basic.compound]], the
 deallocation function shall deallocate the storage referenced by the
 pointer, ending the duration of the region of storage.
-##### Safely-derived pointers <a id="basic.stc.dynamic.safety">[[basic.stc.dynamic.safety]]</a>
-A *traceable pointer object* is
-- an object of an object pointer type [[basic.compound]], or
-- an object of an integral type that is at least as large as
-  `std::intptr_t`, or
-- a sequence of elements in an array of narrow character type
-  [[basic.fundamental]], where the size and alignment of the sequence
-  match those of some object pointer type.
-A pointer value is a *safely-derived pointer* to an object with dynamic
-storage duration only if the pointer value has an object pointer type
-and is one of the following:
-- the value returned by a call to the C++ standard library
-  implementation of `::operator new(std::{}size_t)` or
-  `::operator new(std::size_t, std::align_val_t)` ;[^16]
-- the result of taking the address of an object (or one of its
-  subobjects) designated by an lvalue resulting from indirection through
-  a safely-derived pointer value;
-- the result of well-defined pointer arithmetic [[expr.add]] using a
-  safely-derived pointer value;
-- the result of a well-defined pointer conversion ([[conv.ptr]],
-  [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]]) of a
-  safely-derived pointer value;
-- the result of a `reinterpret_cast` of a safely-derived pointer value;
-- the result of a `reinterpret_cast` of an integer representation of a
-  safely-derived pointer value;
-- the value of an object whose value was copied from a traceable pointer
-  object, where at the time of the copy the source object contained a
-  copy of a safely-derived pointer value.
-An integer value is an *integer representation of a safely-derived
-pointer* only if its type is at least as large as `std::intptr_t` and it
-is one of the following:
-- the result of a `reinterpret_cast` of a safely-derived pointer value;
-- the result of a valid conversion of an integer representation of a
-  safely-derived pointer value;
-- the value of an object whose value was copied from a traceable pointer
-  object, where at the time of the copy the source object contained an
-  integer representation of a safely-derived pointer value;
-- the result of an additive or bitwise operation, one of whose operands
-  is an integer representation of a safely-derived pointer value `P`, if
-  that result converted by `reinterpret_cast<void*>` would compare equal
-  to a safely-derived pointer computable from
-  `reinterpret_cast<void*>(P)`.
-An implementation may have *relaxed pointer safety*, in which case the
-validity of a pointer value does not depend on whether it is a
-safely-derived pointer value. Alternatively, an implementation may have
-*strict pointer safety*, in which case a pointer value referring to an
-object with dynamic storage duration that is not a safely-derived
-pointer value is an invalid pointer value unless the referenced complete
-object has previously been declared reachable [[util.dynamic.safety]].
-[*Note 6*: The effect of using an invalid pointer value (including
-passing it to a deallocation function) is undefined, see  [[basic.stc]].
-This is true even if the unsafely-derived pointer value might compare
-equal to some safely-derived pointer value. — *end note*]
-It is *implementation-defined* whether an implementation has relaxed or
-strict pointer safety.
 #### Duration of subobjects <a id="basic.stc.inherit">[[basic.stc.inherit]]</a>
 The storage duration of subobjects and reference members is that of
 their complete object [[intro.object]].
 ### Alignment <a id="basic.align">[[basic.align]]</a>
-Object types have *alignment requirements* ([[basic.fundamental]],
-[[basic.compound]]) which place restrictions on the addresses at which
-an object of that type may be allocated. An *alignment* is an
-*implementation-defined* integer value representing the number of bytes
-between successive addresses at which a given object can be allocated.
-An object type imposes an alignment requirement on every object of that
-type; stricter alignment can be requested using the alignment specifier
-[[dcl.align]].
 A *fundamental alignment* is represented by an alignment less than or
 equal to the greatest alignment supported by the implementation in all
 contexts, which is equal to `alignof(std::max_align_t)`
-[[support.types]]. The alignment required for a type might be different
 when it is used as the type of a complete object and when it is used as
 the type of a subobject.
 [*Example 1*:
@@ -951,57 +903,55 @@ Comparing alignments is meaningful and provides the obvious results:
 - Two alignments are different when their numeric values are not equal.
 - When an alignment is larger than another it represents a stricter
   alignment.
 [*Note 3*: The runtime pointer alignment function [[ptr.align]] can be
-used to obtain an aligned pointer within a buffer; the aligned-storage
-templates in the library [[meta.trans.other]] can be used to obtain
-aligned storage. — *end note*]
 If a request for a specific extended alignment in a specific context is
 not supported by an implementation, the program is ill-formed.
 ### Temporary objects <a id="class.temporary">[[class.temporary]]</a>
 Temporary objects are created
 - when a prvalue is converted to an xvalue [[conv.rval]],
 - when needed by the implementation to pass or return an object of
-  trivially-copyable type (see below), and
 - when throwing an exception [[except.throw]]. \[*Note 1*: The lifetime
   of exception objects is described in  [[except.throw]]. — *end note*]
 Even when the creation of the temporary object is unevaluated
-[[expr.prop]], all the semantic restrictions shall be respected as if
 the temporary object had been created and later destroyed.
 [*Note 2*: This includes accessibility [[class.access]] and whether it
 is deleted, for the constructor selected and for the destructor.
 However, in the special case of the operand of a *decltype-specifier*
-[[expr.call]], no temporary is introduced, so the foregoing does not
-apply to such a prvalue. — *end note*]
 The materialization of a temporary object is generally delayed as long
 as possible in order to avoid creating unnecessary temporary objects.
 [*Note 3*:
 Temporary objects are materialized:
-- when binding a reference to a prvalue ([[dcl.init.ref]],
-  [[expr.type.conv]], [[expr.dynamic.cast]], [[expr.static.cast]],
-  [[expr.const.cast]], [[expr.cast]]),
-- when performing member access on a class prvalue ([[expr.ref]],
-  [[expr.mptr.oper]]),
 - when performing an array-to-pointer conversion or subscripting on an
-  array prvalue ([[conv.array]], [[expr.sub]]),
 - when initializing an object of type `std::initializer_list<T>` from a
   *braced-init-list* [[dcl.init.list]],
-- for certain unevaluated operands ([[expr.typeid]], [[expr.sizeof]]),
-  and
 - when a prvalue that has type other than cv `void` appears as a
-  discarded-value expression [[expr.prop]].
 — *end note*]
 [*Example 1*:
@@ -1058,38 +1008,38 @@ object).
 [*Note 4*: This latitude is granted to allow objects of class type to
 be passed to or returned from functions in registers. — *end note*]
 When an implementation introduces a temporary object of a class that has
-a non-trivial constructor ([[class.default.ctor]],
-[[class.copy.ctor]]), it shall ensure that a constructor is called for
-the temporary object. Similarly, the destructor shall be called for a
-temporary with a non-trivial destructor [[class.dtor]]. Temporary
-objects are destroyed as the last step in evaluating the full-expression
-[[intro.execution]] that (lexically) contains the point where they were
-created. This is true even if that evaluation ends in throwing an
-exception. The value computations and side effects of destroying a
-temporary object are associated only with the full-expression, not with
-any specific subexpression.
-There are three contexts in which temporaries are destroyed at a
 different point than the end of the full-expression. The first context
 is when a default constructor is called to initialize an element of an
 array with no corresponding initializer [[dcl.init]]. The second context
 is when a copy constructor is called to copy an element of an array
-while the entire array is copied ([[expr.prim.lambda.capture]],
-[[class.copy.ctor]]). In either case, if the constructor has one or more
-default arguments, the destruction of every temporary created in a
-default argument is sequenced before the construction of the next array
-element, if any.
-The third context is when a reference is bound to a temporary
-object.[^17] The temporary object to which the reference is bound or the
-temporary object that is the complete object of a subobject to which the
-reference is bound persists for the lifetime of the reference if the
-glvalue to which the reference is bound was obtained through one of the
-following:
 - a temporary materialization conversion [[conv.rval]],
 - `(` *expression* `)`, where *expression* is one of these expressions,
 - subscripting [[expr.sub]] of an array operand, where that operand is
   one of these expressions,
@@ -1128,11 +1078,11 @@ int&& c = cond ? id<int[3]>{1, 2, 3}[i] : static_cast<int&&>(0);
 — *end example*]
 [*Note 5*:
-An explicit type conversion ([[expr.type.conv]], [[expr.cast]]) is
 interpreted as a sequence of elementary casts, covered above.
 [*Example 3*:
 ``` cpp
@@ -1175,35 +1125,43 @@ The exceptions to this lifetime rule are:
   `return` statement [[stmt.return]] is not extended; the temporary is
   destroyed at the end of the full-expression in the `return` statement.
 - A temporary bound to a reference in a *new-initializer* [[expr.new]]
   persists until the completion of the full-expression containing the
   *new-initializer*.
-  \[*Note 7*: This may introduce a dangling reference. — *end note*]
   \[*Example 5*:
   ``` cpp
   struct S { int mi; const std::pair<int,int>& mp; };
   S a { 1, {2,3} };
   S* p = new S{ 1, {2,3} };       // creates dangling reference
   ```
   — *end example*]
-The destruction of a temporary whose lifetime is not extended by being
-bound to a reference is sequenced before the destruction of every
-temporary which is constructed earlier in the same full-expression. If
-the lifetime of two or more temporaries to which references are bound
-ends at the same point, these temporaries are destroyed at that point in
-the reverse order of the completion of their construction. In addition,
-the destruction of temporaries bound to references shall take into
-account the ordering of destruction of objects with static, thread, or
-automatic storage duration ([[basic.stc.static]], [[basic.stc.thread]],
-[[basic.stc.auto]]); that is, if `obj1` is an object with the same
-storage duration as the temporary and created before the temporary is
-created the temporary shall be destroyed before `obj1` is destroyed; if
-`obj2` is an object with the same storage duration as the temporary and
-created after the temporary is created the temporary shall be destroyed
-after `obj2` is destroyed.
 [*Example 6*:
 ``` cpp
 struct S {

 ## Memory and objects <a id="basic.memobj">[[basic.memobj]]</a>
 ### Memory model <a id="intro.memory">[[intro.memory]]</a>
 The fundamental storage unit in the C++ memory model is the *byte*. A
+byte is at least large enough to contain the ordinary literal encoding
+of any element of the basic literal character set [[lex.charset]] and
+the eight-bit code units of the Unicode[^5]
+UTF-8 encoding form and is composed of a contiguous sequence of
+bits,[^6]
+the number of which is *implementation-defined*. The least significant
+bit is called the *low-order bit*; the most significant bit is called
+the *high-order bit*. The memory available to a C++ program consists of
+one or more sequences of contiguous bytes. Every byte has a unique
+address.
 [*Note 1*: The representation of types is described in
+[[basic.types.general]]. — *end note*]
+A *memory location* is either an object of scalar type that is not a
+bit-field or a maximal sequence of adjacent bit-fields all having
+nonzero width.
 [*Note 2*: Various features of the language, such as references and
 virtual functions, might involve additional memory locations that are
 not accessible to programs but are managed by the
 implementation. — *end note*]
   int b:5,
   c:11,
   :0,
   d:8;
   struct {int ee:8;} e;
+};
 ```
 contains four separate memory locations: The member `a` and bit-fields
 `d` and `e.ee` are each separate memory locations, and can be modified
 concurrently without interfering with each other. The bit-fields `b` and
 The constructs in a C++ program create, destroy, refer to, access, and
 manipulate objects. An *object* is created by a definition
 [[basic.def]], by a *new-expression* [[expr.new]], by an operation that
 implicitly creates objects (see below), when implicitly changing the
 active member of a union [[class.union]], or when a temporary object is
+created [[conv.rval]], [[class.temporary]]. An object occupies a region
+of storage in its period of construction [[class.cdtor]], throughout its
+lifetime [[basic.life]], and in its period of destruction
 [[class.cdtor]].
 [*Note 1*: A function is not an object, regardless of whether or not it
 occupies storage in the way that objects do. — *end note*]
 The properties of an object are determined when the object is created.
 An object can have a name [[basic.pre]]. An object has a storage
 duration [[basic.stc]] which influences its lifetime [[basic.life]]. An
+object has a type [[basic.types]].
+[*Note 2*: Some objects are polymorphic [[class.virtual]]; the
+implementation generates information associated with each such object
+that makes it possible to determine that object’s type during program
+execution. — *end note*]
 Objects can contain other objects, called *subobjects*. A subobject can
 be a *member subobject* [[class.mem]], a *base class subobject*
 [[class.derived]], or an array element. An object that is not a
 subobject of any other object is called a *complete object*. If an
 “array of N `std::byte`” [[cstddef.syn]], that array *provides storage*
 for the created object if:
 - the lifetime of *e* has begun and not ended, and
 - the storage for the new object fits entirely within *e*, and
+- there is no array object that satisfies these constraints nested
+  within *e*.
+[*Note 3*: If that portion of the array previously provided storage for
 another object, the lifetime of that object ends because its storage was
 reused [[basic.life]]. — *end note*]
 [*Example 1*:
 - If `x` is a complete object, then the complete object of `x` is
   itself.
 - Otherwise, the complete object of `x` is the complete object of the
   (unique) object that contains `x`.
+If a complete object, a member subobject, or an array element is of
+class type, its type is considered the *most derived class*, to
 distinguish it from the class type of any base class subobject; an
 object of a most derived class type or of a non-class type is called a
 *most derived object*.
 A *potentially-overlapping subobject* is either:
 - is not a potentially-overlapping subobject, or
 - is not of class type, or
 - is of a class type with virtual member functions or virtual base
   classes, or
+- has subobjects of nonzero size or unnamed bit-fields of nonzero
+  length.
 Otherwise, if the object is a base class subobject of a standard-layout
 class type with no non-static data members, it has zero size. Otherwise,
 the circumstances under which the object has zero size are
 *implementation-defined*. Unless it is a bit-field [[class.bit]], an
 object with nonzero size shall occupy one or more bytes of storage,
 including every byte that is occupied in full or in part by any of its
 subobjects. An object of trivially copyable or standard-layout type
+[[basic.types.general]] shall occupy contiguous bytes of storage.
 Unless an object is a bit-field or a subobject of zero size, the address
 of that object is the address of the first byte it occupies. Two objects
 with overlapping lifetimes that are not bit-fields may have the same
 address if one is nested within the other, or if at least one is a
 subobject of zero size and they are of different types; otherwise, they
+have distinct addresses and occupy disjoint bytes of storage.[^7]
 [*Example 2*:
 ``` cpp
 static const char test1 = 'x';
 Some operations are described as *implicitly creating objects* within a
 specified region of storage. For each operation that is specified as
 implicitly creating objects, that operation implicitly creates and
 starts the lifetime of zero or more objects of implicit-lifetime types
+[[basic.types.general]] in its specified region of storage if doing so
+would result in the program having defined behavior. If no such set of
+objects would give the program defined behavior, the behavior of the
+program is undefined. If multiple such sets of objects would give the
+program defined behavior, it is unspecified which such set of objects is
 created.
+[*Note 4*: Such operations do not start the lifetimes of subobjects of
 such objects that are not themselves of implicit-lifetime
 types. — *end note*]
 Further, after implicitly creating objects within a specified region of
 storage, some operations are described as producing a pointer to a
 }
 ```
 — *end example*]
+An operation that begins the lifetime of an array of `unsigned char` or
+`std::byte` implicitly creates objects within the region of storage
+occupied by the array.
+[*Note 5*: The array object provides storage for these
 objects. — *end note*]
 Any implicit or explicit invocation of a function named `operator new`
 or `operator new[]` implicitly creates objects in the returned region of
 storage and returns a pointer to a suitable created object.
+[*Note 6*: Some functions in the C++ standard library implicitly create
+objects
+[[obj.lifetime]], [[allocator.traits.members]], [[c.malloc]], [[cstring.syn]], [[bit.cast]]. — *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*]
 ### Indeterminate values <a id="basic.indet">[[basic.indet]]</a>
   [[basic.fundamental]] or `std::byte` type [[cstddef.syn]] is produced
   by the evaluation of:
   - the second or third operand of a conditional expression
     [[expr.cond]],
   - the right operand of a comma expression [[expr.comma]],
+  - the operand of a cast or conversion
+    [[conv.integral]], [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]]
+ to an unsigned ordinary character type or `std::byte` type
     [[cstddef.syn]], or
   - a discarded-value expression [[expr.context]],
   then the result of the operation is an indeterminate value.
 - If an indeterminate value of unsigned ordinary character type or
 — *end example*]
 ### Storage duration <a id="basic.stc">[[basic.stc]]</a>
+#### General <a id="basic.stc.general">[[basic.stc.general]]</a>
 The *storage duration* is the property of an object that defines the
 minimum potential lifetime of the storage containing the object. The
 storage duration is determined by the construct used to create the
 object and is one of the following:
 values of all pointers representing the address of any part of that
 region of storage become invalid pointer values [[basic.compound]].
 Indirection through an invalid pointer value and passing an invalid
 pointer value to a deallocation function have undefined behavior. Any
 other use of an invalid pointer value has *implementation-defined*
+behavior.[^10]
 #### Static storage duration <a id="basic.stc.static">[[basic.stc.static]]</a>
+All variables which
+- do not have thread storage duration and
+- belong to a namespace scope [[basic.scope.namespace]] or are first
+  declared with the `static` or `extern` keywords [[dcl.stc]]
+have *static storage duration*. The storage for these entities lasts for
+the duration of the program
+[[basic.start.static]], [[basic.start.term]].
 If a variable with static storage duration has initialization or a
 destructor with side effects, it shall not be eliminated even if it
 appears to be unused, except that a class object or its copy/move may be
 eliminated as specified in  [[class.copy.elision]].
+[*Note 1*:  The keyword `static` can be used to declare a block
+variable [[basic.scope.block]] with static storage duration;
+[[stmt.dcl]] and [[basic.start.term]] describe the initialization and
+destruction of such variables. The keyword `static` applied to a class
+data member in a class definition gives the data member static storage
+duration [[class.static.data]]. — *end note*]
 #### Thread storage duration <a id="basic.stc.thread">[[basic.stc.thread]]</a>
 All variables declared with the `thread_local` keyword have
 *thread storage duration*. The storage for these entities lasts for the
 [[stmt.dcl]] and, if constructed, is destroyed on thread exit
 [[basic.start.term]]. — *end note*]
 #### Automatic storage duration <a id="basic.stc.auto">[[basic.stc.auto]]</a>
+Variables that belong to a block or parameter scope and are not
+explicitly declared `static`, `thread_local`, or `extern` have
+*automatic storage duration*. The storage for these entities lasts until
+the block in which they are created exits.
 [*Note 1*: These variables are initialized and destroyed as described
 in  [[stmt.dcl]]. — *end note*]
 If a variable with automatic storage duration has initialization or a
 it appears to be unused, except that a class object or its copy/move may
 be eliminated as specified in  [[class.copy.elision]].
 #### Dynamic storage duration <a id="basic.stc.dynamic">[[basic.stc.dynamic]]</a>
+##### General <a id="basic.stc.dynamic.general">[[basic.stc.dynamic.general]]</a>
 Objects can be created dynamically during program execution
 [[intro.execution]], using *new-expression*s [[expr.new]], and destroyed
 using *delete-expression*s [[expr.delete]]. A C++ implementation
 provides access to, and management of, dynamic storage via the global
+*allocation functions* `operator new` and `operator new[]` and the
+global *deallocation functions* `operator delete` and
+`operator delete[]`.
 [*Note 1*: The non-allocating forms described in
 [[new.delete.placement]] do not perform allocation or
 deallocation. — *end note*]
 The library provides default definitions for the global allocation and
 deallocation functions. Some global allocation and deallocation
+functions are replaceable [[new.delete]]; these are attached to the
+global module [[module.unit]]. A C++ program shall provide at most one
+definition of a replaceable allocation or deallocation function. Any
+such function definition replaces the default version provided in the
+library [[replacement.functions]]. The following allocation and
+deallocation functions [[support.dynamic]] are implicitly declared in
+global scope in each translation unit of a program.
 ``` cpp
 [[nodiscard]] void* operator new(std::size_t);
 [[nodiscard]] void* operator new(std::size_t, std::align_val_t);
 void operator delete[](void*, std::size_t) noexcept;
 void operator delete[](void*, std::align_val_t) noexcept;
 void operator delete[](void*, std::size_t, std::align_val_t) noexcept;
 ```
+These implicit declarations introduce only the function names
+`operator new`, `operator new[]`, `operator delete`, and
+`operator delete[]`.
 [*Note 2*: The implicit declarations do not introduce the names `std`,
 `std::size_t`, `std::align_val_t`, or any other names that the library
 uses to declare these names. Thus, a *new-expression*,
 *delete-expression*, or function call that refers to one of these
+functions without importing or including the header `<new>` or importing
+a C++ library module [[std.modules]] is well-formed. However, referring
+to `std` or `std::size_t` or `std::align_val_t` is ill-formed unless a
+standard library declaration
+[[cstddef.syn]], [[new.syn]], [[std.modules]] of that name precedes
+[[basic.lookup.general]] the use of that name. — *end note*]
 Allocation and/or deallocation functions may also be declared and
 defined for any class [[class.free]].
 If the behavior of an allocation or deallocation function does not
 [[basic.stc.dynamic.allocation]] and
 [[basic.stc.dynamic.deallocation]], the behavior is undefined.
 ##### Allocation functions <a id="basic.stc.dynamic.allocation">[[basic.stc.dynamic.allocation]]</a>
+An allocation function that is not a class member function shall belong
+to the global scope and not have a name with internal linkage. The
+return type shall be `void*`. The first parameter shall have type
+`std::size_t` [[support.types]]. The first parameter shall not have an
+associated default argument [[dcl.fct.default]]. The value of the first
+parameter is interpreted as the requested size of the allocation. An
+allocation function can be a function template. Such a template shall
+declare its return type and first parameter as specified above (that is,
+template parameter types shall not be used in the return type and first
+parameter type). Allocation function templates shall have two or more
+parameters.
 An allocation function attempts to allocate the requested amount of
 storage. If it is successful, it returns the address of the start of a
 block of storage whose length in bytes is at least as large as the
 requested size. The order, contiguity, and initial value of storage
 subsequently passed to a replaceable deallocation function. Furthermore,
 for the library allocation functions in  [[new.delete.single]] and
 [[new.delete.array]], `p0` represents the address of a block of storage
 disjoint from the storage for any other object accessible to the caller.
 The effect of indirecting through a pointer returned from a request for
+zero size is undefined.[^11]
 For an allocation function other than a reserved placement allocation
 function [[new.delete.placement]], the pointer returned on a successful
 call shall represent the address of storage that is aligned as follows:
 [[expr.typeid]], or for an exception object
 [[except.throw]]. — *end note*]
 ##### Deallocation functions <a id="basic.stc.dynamic.deallocation">[[basic.stc.dynamic.deallocation]]</a>
+A deallocation function that is not a class member function shall belong
+to the global scope and not have a name with internal linkage.
 A deallocation function is a *destroying operator delete* if it has at
 least two parameters and its second parameter is of type
 `std::destroying_delete_t`. A destroying operator delete shall be a
 class member function named `operator delete`.
 parameter shall be `void*`. A deallocation function may have more than
 one parameter. A *usual deallocation function* is a deallocation
 function whose parameters after the first are
 - optionally, a parameter of type `std::destroying_delete_t`, then
+- optionally, a parameter of type `std::size_t`,[^12] then
 - optionally, a parameter of type `std::align_val_t`.
 A destroying operator delete shall be a usual deallocation function. A
 deallocation function may be an instance of a function template. Neither
 the first parameter nor the return type shall depend on a template
 If the argument given to a deallocation function in the standard library
 is a pointer that is not the null pointer value [[basic.compound]], the
 deallocation function shall deallocate the storage referenced by the
 pointer, ending the duration of the region of storage.
 #### Duration of subobjects <a id="basic.stc.inherit">[[basic.stc.inherit]]</a>
 The storage duration of subobjects and reference members is that of
 their complete object [[intro.object]].
 ### Alignment <a id="basic.align">[[basic.align]]</a>
+Object types have *alignment requirements*
+[[basic.fundamental]], [[basic.compound]] which place restrictions on
+the addresses at which an object of that type may be allocated. An
+*alignment* is an *implementation-defined* integer value representing
+the number of bytes between successive addresses at which a given object
+can be allocated. An object type imposes an alignment requirement on
+every object of that type; stricter alignment can be requested using the
+alignment specifier [[dcl.align]].
 A *fundamental alignment* is represented by an alignment less than or
 equal to the greatest alignment supported by the implementation in all
 contexts, which is equal to `alignof(std::max_align_t)`
+[[support.types]]. The alignment required for a type may be different
 when it is used as the type of a complete object and when it is used as
 the type of a subobject.
 [*Example 1*:
 - Two alignments are different when their numeric values are not equal.
 - When an alignment is larger than another it represents a stricter
   alignment.
 [*Note 3*: The runtime pointer alignment function [[ptr.align]] can be
+used to obtain an aligned pointer within a buffer; an
+*alignment-specifier* [[dcl.align]] can be used to align storage
+explicitly. — *end note*]
 If a request for a specific extended alignment in a specific context is
 not supported by an implementation, the program is ill-formed.
 ### Temporary objects <a id="class.temporary">[[class.temporary]]</a>
 Temporary objects are created
 - when a prvalue is converted to an xvalue [[conv.rval]],
 - when needed by the implementation to pass or return an object of
+  trivially copyable type (see below), and
 - when throwing an exception [[except.throw]]. \[*Note 1*: The lifetime
   of exception objects is described in  [[except.throw]]. — *end note*]
 Even when the creation of the temporary object is unevaluated
+[[expr.context]], all the semantic restrictions shall be respected as if
 the temporary object had been created and later destroyed.
 [*Note 2*: This includes accessibility [[class.access]] and whether it
 is deleted, for the constructor selected and for the destructor.
 However, in the special case of the operand of a *decltype-specifier*
+[[dcl.type.decltype]], no temporary is introduced, so the foregoing does
+not apply to such a prvalue. — *end note*]
 The materialization of a temporary object is generally delayed as long
 as possible in order to avoid creating unnecessary temporary objects.
 [*Note 3*:
 Temporary objects are materialized:
+- when binding a reference to a prvalue
+  [[dcl.init.ref]], [[expr.type.conv]], [[expr.dynamic.cast]], [[expr.static.cast]], [[expr.const.cast]], [[expr.cast]],
+- when performing member access on a class prvalue
+ [[expr.ref]], [[expr.mptr.oper]],
 - when performing an array-to-pointer conversion or subscripting on an
+  array prvalue [[conv.array]], [[expr.sub]],
 - when initializing an object of type `std::initializer_list<T>` from a
   *braced-init-list* [[dcl.init.list]],
+- for certain unevaluated operands [[expr.typeid]], [[expr.sizeof]], and
 - when a prvalue that has type other than cv `void` appears as a
+  discarded-value expression [[expr.context]].
 — *end note*]
 [*Example 1*:
 [*Note 4*: This latitude is granted to allow objects of class type to
 be passed to or returned from functions in registers. — *end note*]
 When an implementation introduces a temporary object of a class that has
+a non-trivial constructor [[class.default.ctor]], [[class.copy.ctor]],
+it shall ensure that a constructor is called for the temporary object.
+Similarly, the destructor shall be called for a temporary with a
+non-trivial destructor [[class.dtor]]. Temporary objects are destroyed
+as the last step in evaluating the full-expression [[intro.execution]]
+that (lexically) contains the point where they were created. This is
+true even if that evaluation ends in throwing an exception. The value
+computations and side effects of destroying a temporary object are
+associated only with the full-expression, not with any specific
+subexpression.
+There are four contexts in which temporaries are destroyed at a
 different point than the end of the full-expression. The first context
 is when a default constructor is called to initialize an element of an
 array with no corresponding initializer [[dcl.init]]. The second context
 is when a copy constructor is called to copy an element of an array
+while the entire array is copied
+[[expr.prim.lambda.capture]], [[class.copy.ctor]]. In either case, if
+the constructor has one or more default arguments, the destruction of
+every temporary created in a default argument is sequenced before the
+construction of the next array element, if any.
+The third context is when a reference binds to a temporary object.[^13]
+The temporary object to which the reference is bound or the temporary
+object that is the complete object of a subobject to which the reference
+is bound persists for the lifetime of the reference if the glvalue to
+which the reference is bound was obtained through one of the following:
 - a temporary materialization conversion [[conv.rval]],
 - `(` *expression* `)`, where *expression* is one of these expressions,
 - subscripting [[expr.sub]] of an array operand, where that operand is
   one of these expressions,
 — *end example*]
 [*Note 5*:
+An explicit type conversion [[expr.type.conv]], [[expr.cast]] is
 interpreted as a sequence of elementary casts, covered above.
 [*Example 3*:
 ``` cpp
   `return` statement [[stmt.return]] is not extended; the temporary is
   destroyed at the end of the full-expression in the `return` statement.
 - A temporary bound to a reference in a *new-initializer* [[expr.new]]
   persists until the completion of the full-expression containing the
   *new-initializer*.
+  \[*Note 7*: This might introduce a dangling reference. — *end note*]
   \[*Example 5*:
   ``` cpp
   struct S { int mi; const std::pair<int,int>& mp; };
   S a { 1, {2,3} };
   S* p = new S{ 1, {2,3} };       // creates dangling reference
   ```
   — *end example*]
+The fourth context is when a temporary object other than a function
+parameter object is created in the *for-range-initializer* of a
+range-based `for` statement. If such a temporary object would otherwise
+be destroyed at the end of the *for-range-initializer* full-expression,
+the object persists for the lifetime of the reference initialized by the
+*for-range-initializer*.
+The destruction of a temporary whose lifetime is not extended beyond the
+full-expression in which it was created is sequenced before the
+destruction of every temporary which is constructed earlier in the same
+full-expression. If the lifetime of two or more temporaries with
+lifetimes extending beyond the full-expressions in which they were
+created ends at the same point, these temporaries are destroyed at that
+point in the reverse order of the completion of their construction. In
+addition, the destruction of such temporaries shall take into account
+the ordering of destruction of objects with static, thread, or automatic
+storage duration
+[[basic.stc.static]], [[basic.stc.thread]], [[basic.stc.auto]]; that is,
+if `obj1` is an object with the same storage duration as the temporary
+and created before the temporary is created the temporary shall be
+destroyed before `obj1` is destroyed; if `obj2` is an object with the
+same storage duration as the temporary and created after the temporary
+is created the temporary shall be destroyed after `obj2` is destroyed.
 [*Example 6*:
 ``` cpp
 struct S {

Diff to HTML by rtfpessoa