Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://en.cppreference.com/w/cpp/language/../named_req/AllocatorAwareContainer.html below:

C++ named requirements: AllocatorAwareContainer (since C++11)

An AllocatorAwareContainer is a Container that holds an instance of an Allocator and uses that instance in all its member functions to allocate and deallocate memory and to construct and destroy objects in that memory (such objects may be container elements, nodes, or, for unordered containers, bucket arrays), except that std::basic_string specializations do not use the allocators for construction/destruction of their elements(since C++23).

The following rules apply to container construction:

• Copy constructors of AllocatorAwareContainers obtain their instances of the allocator by calling std::allocator_traits<allocator_type>::select_on_container_copy_construction on the allocator of the container being copied.
• Move constructors obtain their instances of allocators by move-constructing from the allocator belonging to the old container.
• All other constructors take a const allocator_type& parameter.

The only way to replace an allocator is copy-assignment, move-assignment, and swap:

• Copy-assignment will replace the allocator only if std::allocator_traits<allocator_type>::propagate_on_container_copy_assignment::value is true.
• Move-assignment will replace the allocator only if std::allocator_traits<allocator_type>::propagate_on_container_move_assignment::value is true.
• Swap will replace the allocator only if std::allocator_traits<allocator_type>::propagate_on_container_swap::value is true. Specifically, it will exchange the allocator instances through an unqualified call to the non-member function swap, see Swappable. If swap does not propagate the allocator, swapping two containers with unequal allocators is undefined behavior.
• The accessor get_allocator() obtains a copy of the allocator that was used to construct the container or installed by the most recent allocator replacement operation.

The only exception is std::basic_string<CharT,Traits,Allocator>::assign, which may also propagate the allocator.

A type satisfies AllocatorAwareContainer if it satisfies Container and, given the following types and values, the semantic and complexity requirements in the tables below are satisfied:

• u has the same elements as rv had before this construction.
• The value of u.get_allocator() is the same as the value of rv.get_allocator() before this construction.

• Constant if m == rv.get_allocator() is true.
• Otherwise linear.

• u has the same elements, or copies of the elements, that rv had before this construction.
• u.get_allocator() == m is true.

AllocatorAwareContainers always call std::allocator_traits<A>::construct(m, p, args) to construct an object of type T at p using args, with m == get_allocator(). The default construct in std::allocator calls ::new((void*)p) T(args)(until C++20)std::allocator has no construct member and std::construct_at(p, args) is called when constructing elements(since C++20), but specialized allocators may choose a different definition.

All standard library string types and containers (except std::array and std::inplace_vector) are AllocatorAwareContainers:

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4