[basic.memobj] (original) (raw)

6 Basics [basic]

6.7 Memory and objects [basic.memobj]

6.7.1 Memory model [intro.memory]

The fundamental storage unit in the C++ memory model is thebyte.

A byte is at least large enough to contain any member of theexecution character set ([lex.charset]) and the eight-bit code units of the Unicode30UTF-8 encoding form and is composed of a contiguous sequence of bits,31the 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 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_]

Two or more threads of execution can access separate memory locations without interfering with each other.

[Note 3:

Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can be concurrently updated by two threads of execution without interference.

The same applies to two bit-fields, if one is declared inside a nested struct declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field declaration.

It is not safe to concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of nonzero width.

— _end note_]

[Example 1:

A class declared asstruct { char a;int b:5, c:11,:0, d:8;struct {int ee:8;} e;} contains four separate memory locations: The member a and bit-fieldsd and e.ee are each separate memory locations, and can be modified concurrently without interfering with each other.

The bit-fieldsb and c together constitute the fourth memory location.

The bit-fields b and c cannot be concurrently modified, butb and a, for example, can be.

— _end example_]

6.7.2 Object model [intro.object]

The constructs in a C++ program create, destroy, refer to, access, and manipulate objects.

An object is created by a definition, by a new-expression ([expr.new]), by an operation that implicitly creates objects (see below), when implicitly changing the active member of a 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, 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 has a storage duration ([basic.stc]) which influences its lifetime ([basic.life]).

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 expressions ([expr.compound]) used to access them.

Objects can contain other objects, called subobjects.

An object that is not a subobject of any other object is called a complete object.

If an object is created in storage associated with a member subobject or array element e(which may or may not be within its lifetime), the created object is a subobject of e's containing object if:

If a complete object is created ([expr.new]) in storage associated with another object _e_of type “array of N unsigned char” or of type “array of N std​::​byte” ([cstddef.syn]), that array provides storagefor the created object if:

[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: template<typename ...T> struct AlignedUnion { alignas(T...) unsigned char data[max(sizeof(T)...)];};int f() { AlignedUnion<int, char> au;int *p = new (au.data) int; char *c = new (au.data) char(); char *d = new (au.data + 1) char();return *c + *d; } struct A { unsigned char a[32]; };struct B { unsigned char b[16]; }; A a; B *b = new (a.a + 8) B; int *p = new (b->b + 4) int; — _end example_]

An object a is nested within another object b if:

For every object x, there is some object called thecomplete object of x, determined as follows:

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 amost derived object.

A potentially-overlapping subobject is either:

An object has nonzero size if it

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, 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.32

[Example 2: static const char test1 = 'x';static const char test2 = 'x';const bool b = &test1 != &test2; — _end example_]

The address of a non-bit-field subobject of zero size is the address of an unspecified byte of storage occupied by the complete object of that subobject.

Some operations are described asimplicitly creating objectswithin 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 asuitable created object.

These operations select one of the implicitly-created objects whose address is the address of the start of the region of storage, and produce a pointer value that points to that object, if that value would result in the program having defined behavior.

If no such pointer value would give the program defined behavior, the behavior of the program is undefined.

If multiple such pointer values would give the program defined behavior, it is unspecified which such pointer value is produced.

[Example 3: #include <cstdlib> struct X { int a, b; }; X *make_x() { X *p = (X*)std::malloc(sizeof(struct X)); p->a = 1; p->b = 2;return p;} — _end example_]

An operation that begins the lifetime of an array of char, unsigned char, or std​::​byteimplicitly 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.

6.7.3 Lifetime [basic.life]

The lifetime of an object or reference is a runtime property of the object or reference.

A variable is said to have vacuous initializationif 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:

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:

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 allocated33or, 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:

[Example 1: #include <cstdlib> struct B { virtual void f();void mutate();virtual ~B();};struct D1 : B { void f(); };struct D2 : B { void f(); };void B::mutate() { new (this) D2; f(); ... = this; } void g() { void* p = std::malloc(sizeof(D1) + sizeof(D2)); B* pb = new (p) D1; pb->mutate();*pb; void* q = pb; pb->f(); } — _end example_]

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.allocation]), and using the properties of the glvalue that do not depend on its value is well-defined.

The program has undefined behavior if:

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 is transparently replaceableby an object if:

[Example 2: struct C { int i;void f();const C& operator=( const C& );};const C& C::operator=( const C& other) { if ( this != &other ) { this->~C(); new (this) C(other); f(); } return *this;}C c1; C c2; c1 = c2; c1.f(); — _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,34and 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: class T { };struct B { ~B();};void h() { B b;new (&b) T;} — _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: struct B { B();~B();};const B b;void h() { b.~B();new (const_cast<B*>(&b)) const 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_]

6.7.4 Indeterminate values [basic.indet]

When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced ([expr.ass]).

[Note 1:

Objects with static or thread storage duration are zero-initialized, see [basic.start.static].

— _end note_]

If an indeterminate value is produced by an evaluation, the behavior is undefined except in the following cases:

[Example 1: int f(bool b) { unsigned char c;unsigned char d = c; int e = d; return b ? d : 0; } — _end example_]

6.7.5 Storage duration [basic.stc]

6.7.5.1 General [basic.stc.general]

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:

Static, thread, and automatic storage durations are associated with objects introduced by declarations ([basic.def]) and implicitly created by the implementation.

The storage duration categories apply to references as well.

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.

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 hasimplementation-defined behavior.35

6.7.5.2 Static storage duration [basic.stc.static]

All variables which do not have dynamic storage duration, do not have thread storage duration, and are not local have static storage duration.

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.

6.7.5.3 Thread storage duration [basic.stc.thread]

All variables declared with the thread_­local keyword havethread storage duration.

The storage for these entities lasts for the duration of the thread in which they are created.

There is a distinct object or reference per thread, and use of the declared name refers to the entity associated with the current thread.

6.7.5.4 Automatic storage duration [basic.stc.auto]

Block-scope variables not explicitly declared static, thread_­local, or extern haveautomatic 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 destructor with side effects, an implementation shall not destroy it 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].

6.7.5.5 Dynamic storage duration [basic.stc.dynamic]

6.7.5.5.1 General [basic.stc.dynamic.general]

A C++ implementation provides access to, and management of, dynamic storage via the globalallocation 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.

[[nodiscard]] void* operator new(std::size_t);[[nodiscard]] void* operator new(std::size_t, std::align_val_t);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;[[nodiscard]] void* operator new[](std::size_t);[[nodiscard]] void* operator new[](std::size_t, std::align_val_t);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 namesoperator 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 is well-formed.

However, referring to stdor std​::​size_­tor std​::​align_­val_­tis 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 satisfy the semantic constraints specified in [basic.stc.dynamic.allocation]and [basic.stc.dynamic.deallocation], the behavior is undefined.

6.7.5.5.2 Allocation functions [basic.stc.dynamic.allocation]

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 allocated by successive calls to an allocation function are unspecified.

Even if the size of the space requested is zero, the request can fail.

If the request succeeds, the value returned by a replaceable allocation function is a non-null pointer value ([basic.compound])p0 different 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.36

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:

An allocation function that fails to allocate storage can invoke the currently installed new-handler function ([new.handler]), if any.

[Note 1:

A program-supplied allocation function can obtain the address of the currently installed new_­handler using thestd​::​get_­new_­handler function ([get.new.handler]).

— _end note_]

An allocation function that has a non-throwing exception specification ([except.spec]) indicates failure by returning a null pointer value.

Any other allocation function never returns a null pointer value and indicates failure only by throwing an exception ([except.throw]) of a type that would match a handler ([except.handle]) of typestd​::​bad_­alloc ([bad.alloc]).

A global allocation function is only called as the result of a new expression, or called directly using the function callsyntax, or called indirectly to allocate storage for a coroutine state ([dcl.fct.def.coroutine]), or called indirectly through calls to the functions in the C++ standard library.

[Note 2:

In particular, a global allocation function is not called to allocate storage for objects with static storage duration, for objects or references with thread storage duration, for objects of type std​::​type_­info, or for anexception object.

— _end note_]

6.7.5.5.3 Deallocation functions [basic.stc.dynamic.deallocation]

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 deleteif 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.

[Note 1:

Array deletion cannot use a destroying operator delete.

— _end note_]

Each deallocation function shall return void.

If the function is a destroying operator delete declared in class type C, the type of its 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

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 parameter.

A deallocation function template shall have two or more function parameters.

A template instance is never a usual deallocation function, regardless of its signature.

If a deallocation function terminates by throwing an exception, the behavior is undefined.

The value of the first argument supplied to a deallocation function may be a null pointer value; if so, and if the deallocation function is one supplied in the standard library, the call 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.

6.7.5.5.4 Safely-derived pointers [basic.stc.dynamic.safety]

A traceable pointer object is

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:

An integer value is an integer representation of a safely-derived pointeronly if its type is at least as large as std​::​intptr_­t and it is one of the following:

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 1:

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 isimplementation-defined whether an implementation has relaxed or strict pointer safety.

6.7.5.6 Duration of subobjects [basic.stc.inherit]

The storage duration of subobjects and reference members is that of their complete object ([intro.object]).

6.7.6 Alignment [basic.align]

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.

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 toalignof(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: struct B { long double d; };struct D : virtual B { char c; };

When D is the type of a complete object, it will have a subobject of type B, so it must be aligned appropriately for a long double.

If D appears as a subobject of another object that also has Bas a virtual base class, the B subobject might be part of a different subobject, reducing the alignment requirements on the D subobject.

— _end example_]

The result of the alignof operator reflects the alignment requirement of the type in the complete-object case.

An extended alignment is represented by an alignment greater than alignof(std​::​max_­align_­t).

It is implementation-defined whether any extended alignments are supported and the contexts in which they are supported ([dcl.align]).

A type having an extended alignment requirement is an over-aligned type.

[Note 1:

Every over-aligned type is or contains a class type to which extended alignment applies (possibly through a non-static data member).

— _end note_]

A new-extended alignment is represented by an alignment greater than __STDCPP_­DEFAULT_­NEW_­ALIGNMENT__ ([cpp.predefined]).

Alignments are represented as values of the type std​::​size_­t.

Valid alignments include only those values returned by an alignofexpression for the fundamental types plus an additional implementation-defined set of values, which may be empty.

Every alignment value shall be a non-negative integral power of two.

Alignments have an order from weaker tostronger or stricter alignments.

Stricter alignments have larger alignment values.

An address that satisfies an alignment requirement also satisfies any weaker valid alignment requirement.

The alignment requirement of a complete type can be queried using analignof expression.

[Note 2:

This enables the ordinary character types to be used as the underlying type for an aligned memory area ([dcl.align]).

— _end note_]

Comparing alignments is meaningful and provides the obvious results:

[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.

6.7.7 Temporary objects [class.temporary]

Temporary objects are created

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 adecltype-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:

— _end note_]

[Example 1:

Consider the following code:class X { public: X(int); X(const X&); X& operator=(const X&);~X();};class Y { public: Y(int); Y(Y&&);~Y();}; X f(X); Y g(Y);void h() { X a(1); X b = f(X(2)); Y c = g(Y(3)); a = f(a);}

X(2) is constructed in the space used to hold f()'s argument andY(3) is constructed in the space used to hold g()'s argument.

Likewise,f()'s result is constructed directly in b andg()'s result is constructed directly in c.

On the other hand, the expressiona = f(a)requires a temporary for the result of f(a), which is materialized so that the reference parameter of X​::​operator=(const X&) can bind to it.

— _end example_]

When an object of class type Xis passed to or returned from a function, if X has at least one eligible copy or move constructor ([special]), each such constructor is trivial, and the destructor of X is either trivial or deleted, implementations are permitted to create a temporary object to hold the function parameter or result object.

The temporary object is constructed from the function argument or return value, respectively, and the function's parameter or return object is initialized as if by using the eligible trivial constructor to copy the temporary (even if that constructor is inaccessible or would not be selected by overload resolution to perform a copy or move of the 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.

Thevalue computations andside 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]).

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.39

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:

[Example 2: template<typename T> using id = T;int i = 1;int&& a = id<int[3]>{1, 2, 3}[i]; const int& b = static_cast<const int&>(0); 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: const int& x = (const int&)1; — _end example_]

— _end note_]

[Note 6:

If a temporary object has a reference member initialized by another temporary object, lifetime extension applies recursively to such a member's initializer.

[Example 4: struct S { const int& m;};const S& s = S{1}; — _end example_]

— _end note_]

The exceptions to this lifetime rule are:

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, ifobj1is an object with the same storage duration as the temporary and created before the temporary is created the temporary shall be destroyed beforeobj1is destroyed; ifobj2is an object with the same storage duration as the temporary and created after the temporary is created the temporary shall be destroyed afterobj2is destroyed.

[Example 6: struct S { S(); S(int);friend S operator+(const S&, const S&);~S();}; S obj1;const S& cr = S(16)+S(23); S obj2;

The expressionS(16) + S(23)creates three temporaries: a first temporaryT1to hold the result of the expressionS(16), a second temporaryT2to hold the result of the expressionS(23), and a third temporaryT3to hold the result of the addition of these two expressions.

The temporaryT3is then bound to the referencecr.

It is unspecified whetherT1orT2is created first.

On an implementation whereT1is created beforeT2,T2shall be destroyed beforeT1.

The temporariesT1andT2are bound to the reference parameters ofoperator+; these temporaries are destroyed at the end of the full-expression containing the call tooperator+.

The temporaryT3bound to the referencecris destroyed at the end ofcr's lifetime, that is, at the end of the program.

In addition, the order in whichT3is destroyed takes into account the destruction order of other objects with static storage duration.

That is, becauseobj1is constructed beforeT3, andT3is constructed beforeobj2,obj2shall be destroyed beforeT3, andT3shall be destroyed beforeobj1.

— _end example_]