Namespaces
Variants
Views
Actions

Difference between revisions of "cpp/named req/Erasable"

From cppreference.com
< cpp‎ | named req
m (Text replace - "{{concept" to "{{named req")
(Wording update.)
 
(9 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{cpp/named req/title|Erasable}}
+
{{cpp/named req/title|Erasable|notes={{mark since c++11}}}}
 
{{cpp/named req/navbar}}
 
{{cpp/named req/navbar}}
  
Line 5: Line 5:
  
 
===Requirements===
 
===Requirements===
 
+
Given the following types, values and expressions:
The type {{ttb|T}} is {{named req|Erasable}} from the {{named req|Container}} {{ttb|X}} whose {{tt|value_type}} is identical to {{tt|T}} if, given
+
 
{{dsc begin}}
 
{{dsc begin}}
{{dsc | {{ttb|A}} | an allocator type}}
+
{{dsc hitem|Type|Definition}}
{{dsc | {{ttb|m}} | an lvalue of type {{ttb|A}} }}
+
{{dsc|{{tt|T}}|an object type}}
{{dsc | {{ttb|p}} | the pointer of type {{ttb|T*}} prepared by the container }}
+
{{dsc|{{tt|A}}|an allocator type}}
 +
{{dsc|{{tt|X}}|a container type satisfying all following conditions:
 +
* {{tt|X::value_type}} is the same as {{tt|T}}.
 +
* {{tt|X::allocator_type}} is the same as {{c/core|std::allocator_traits<A>::rebind_alloc<T>}}.
 +
}}
 +
{{dsc hitem|Value|Definition}}
 +
{{dsc|{{c|m}}|an lvalue of type {{tt|A}}}}
 +
{{dsc|{{c|p}}|a pointer of type {{tt|T*}}}}
 
{{dsc end}}
 
{{dsc end}}
  
where {{ttb|X::allocator_type}} is identical to {{c|std::allocator_traits<A>::rebind_alloc<T>}},
+
If the expression {{c|std::allocator_traits<A>::destroy(m, p)}} is well-formed, {{tt|T}} is {{named req/core|Erasable}} from {{tt|X}}.
  
the following expression is well-formed:
+
===Notes===
 +
All [[cpp/container|standard library containers]] require that their value types satisfy {{named req/core|Erasable}}.
  
{{source|
+
{{rrev multi
std::allocator_traits<A>::destroy(m, p);
+
|until1=c++20|rev1=
 +
With the default allocator, this requirement is equivalent to the validity of {{c|p->~T()}}, which accepts class types with accessible destructors and all scalar types, but rejects array types, function types, reference types, and {{c/core|void}}.
 +
|rev2=
 +
With the default allocator, this requirement is equivalent to the validity of {{c|std::destroy_at(p)}}, which accepts class types with accessible destructors and all scalar types, as well as arrays thereof.
 
}}
 
}}
  
If {{ttb|X}} is not allocator-aware, the term is defined as if {{ttb|A}} were {{c|std::allocator<T>}}, except that no allocator object needs to be created, and user-defined specializations of {{lc|std::allocator}} are not instantiated.
+
Although it is required that customized {{tt|destroy}} is used when destroying elements of {{lc|std::basic_string}} until C++23, all implementations only used the default mechanism. The requirement is corrected by {{wg21|P1072R10}} to match existing practice.
 
+
===Notes===
+
All [[cpp/container|standard library containers]] require that their element type satisfies Erasable.
+
  
With the default allocator, this requirement is equivalent to the validity of {{c|p->~T()}}, which accepts class types with accessible destructors and all scalar types, but rejects array types, function types, reference types, and void.
+
===Defect reports===
 +
{{dr list begin}}
 +
{{dr list item|paper=N3346|std=C++11|before=there was no requirement to specify whether a type<br>whose objects can be destroyed using allocators|after=added the requirement}}
 +
{{dr list end}}
  
===See Also===
+
===See also===
 
{{dsc begin}}
 
{{dsc begin}}
{{dsc | {{named req|CopyInsertable}} }}
+
{{dsc|{{named req|CopyInsertable}}}}
{{dsc | {{named req|MoveInsertable}} }}
+
{{dsc|{{named req|MoveInsertable}}}}
{{dsc | {{named req|EmplaceConstructible}} }}
+
{{dsc|{{named req|EmplaceConstructible}}}}
{{dsc | {{named req|Destructible}} }}
+
{{dsc|{{named req|Destructible}}}}
 
{{dsc end}}
 
{{dsc end}}
  
{{langlinks|zh}}
+
{{langlinks|de|es|ja|ru|zh}}

Latest revision as of 18:14, 6 November 2024

 
 
C++ named requirements
 

Specifies that an object of the type can be destroyed by a given Allocator.

Contents

[edit] Requirements

Given the following types, values and expressions:

Type Definition
T an object type
A an allocator type
X a container type satisfying all following conditions:
  • X::value_type is the same as T.
  • X::allocator_type is the same as std::allocator_traits<A>::rebind_alloc<T>.
Value Definition
m an lvalue of type A
p a pointer of type T*

If the expression std::allocator_traits<A>::destroy(m, p) is well-formed, T is Erasable from X.

[edit] Notes

All standard library containers require that their value types satisfy Erasable.

With the default allocator, this requirement is equivalent to the validity of p->~T(), which accepts class types with accessible destructors and all scalar types, but rejects array types, function types, reference types, and void.

(until C++20)

With the default allocator, this requirement is equivalent to the validity of std::destroy_at(p), which accepts class types with accessible destructors and all scalar types, as well as arrays thereof.

(since C++20)

Although it is required that customized destroy is used when destroying elements of std::basic_string until C++23, all implementations only used the default mechanism. The requirement is corrected by P1072R10 to match existing practice.

[edit] Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR Applied to Behavior as published Correct behavior
N3346 C++11 there was no requirement to specify whether a type
whose objects can be destroyed using allocators
added the requirement

[edit] See also

CopyInsertable
MoveInsertable
EmplaceConstructible
Destructible