Namespaces
Variants
Views
Actions

Difference between revisions of "cpp/memory/scoped allocator adaptor/construct"

From cppreference.com
(LWG 2586)
(2975)
Line 66: Line 66:
  
 
Otherwise, compilation error is issued because although {{tt|std::uses_allocator<T>}} claimed that {{tt|T}} is allocator-aware, it lacks either form of allocator-accepting constructors.
 
Otherwise, compilation error is issued because although {{tt|std::uses_allocator<T>}} claimed that {{tt|T}} is allocator-aware, it lacks either form of allocator-accepting constructors.
 +
 +
{{cpp/enable if|{{tt|U}} is not a specialization of {{lc|std::pair}}}}.
  
 
2) First, if either {{tt|T1}} or {{tt|T2}} is allocator-aware, modifies the tuples {{tt|x}} and {{tt|y}} to include the appropriate inner allocator, resulting in the two new tuples {{tt|xprime}} and {{tt|yprime}}, according to the following three rules:
 
2) First, if either {{tt|T1}} or {{tt|T2}} is allocator-aware, modifies the tuples {{tt|x}} and {{tt|y}} to include the appropriate inner allocator, resulting in the two new tuples {{tt|xprime}} and {{tt|yprime}}, according to the following three rules:
Line 128: Line 130:
 
===Notes===
 
===Notes===
 
This function is called (through {{lc|std::allocator_traits}}) by any allocator-aware object, such as {{lc|std::vector}}, that was given a {{lc|std::scoped_allocator_adaptor}} as the allocator to use. Since {{tt|inner_allocator}} is itself an instance of {{lc|std::scoped_allocator_adaptor}}, this function will also be called when the allocator-aware objects constructed through this function start constructing their own members.
 
This function is called (through {{lc|std::allocator_traits}}) by any allocator-aware object, such as {{lc|std::vector}}, that was given a {{lc|std::scoped_allocator_adaptor}} as the allocator to use. Since {{tt|inner_allocator}} is itself an instance of {{lc|std::scoped_allocator_adaptor}}, this function will also be called when the allocator-aware objects constructed through this function start constructing their own members.
 +
 +
=== Defect reports ===
 +
{{dr list begin}}
 +
{{dr list item|wg=lwg|dr=2975|std=C++11|before=first overload is mistakenly used for pair construction in some cases|after=constrained to not accept pairs}}
 +
{{dr list end}}
  
 
===See also===
 
===See also===
Line 135: Line 142:
 
{{dsc end}}
 
{{dsc end}}
  
[[de:cpp/memory/scoped allocator adaptor/construct]]
+
{{langlinks|de|es|fr|it|ja|pt|ru|zh}}
[[es:cpp/memory/scoped allocator adaptor/construct]]
+
[[fr:cpp/memory/scoped allocator adaptor/construct]]
+
[[it:cpp/memory/scoped allocator adaptor/construct]]
+
[[ja:cpp/memory/scoped allocator adaptor/construct]]
+
[[pt:cpp/memory/scoped allocator adaptor/construct]]
+
[[ru:cpp/memory/scoped allocator adaptor/construct]]
+
[[zh:cpp/memory/scoped allocator adaptor/construct]]
+

Revision as of 06:37, 18 March 2018

 
 
Dynamic memory management
Uninitialized memory algorithms
Constrained uninitialized memory algorithms
Allocators
Garbage collection support
(C++11)(until C++23)
(C++11)(until C++23)
(C++11)(until C++23)
(C++11)(until C++23)
(C++11)(until C++23)
(C++11)(until C++23)



 
 
Defined in header <scoped_allocator>
template < class T, class... Args >
void construct( T* p, Args&&... args );
(1)
template< class T1, class T2, class... Args1, class... Args2 >

void construct( std::pair<T1, T2>* p,
                std::piecewise_construct_t,
                std::tuple<Args1...> x,

                std::tuple<Args2...> y );
(2)
template< class T1, class T2 >
void construct( std::pair<T1, T2>* p );
(3)
template< class T1, class T2, class U, class V >
void construct( std::pair<T1, T2>* p, U&& x, V&& y );
(4)
template< class T1, class T2, class U, class V >
void construct( std::pair<T1, T2>* p, const std::pair<U, V>& xy );
(5)
template< class T1, class T2, class U, class V >
void construct( std::pair<T1, T2>* p, std::pair<U, V>&& xy );
(6)

Constructs an object in allocated, but not initialized storage pointed to by p using OuterAllocator and the provided constructor arguments. If the object is of type that itself uses allocators, or if it is std::pair, passes InnerAllocator down to the constructed object.

First, determines the outermost allocator type OUTERMOST: it is the type that would be returned by calling this->outer_allocator(), and then calling the outer_allocator() member function recursively on the result of this call until reaching the type that has no such member function. That type is the outermost allocator.

Then:

1) If std::uses_allocator<T, inner_allocator_type>::value==false (the type T does not use allocators) and if std::is_constructible<T, Args...>::value==true, then calls

std::allocator_traits<OUTERMOST>::construct( OUTERMOST(*this),
                                             p,
                                             std::forward<Args>(args)... );

Otherwise, if std::uses_allocator<T, inner_allocator_type>::value==true (the type T uses allocators, e.g. it is a container) and if std::is_constructible<T, std::allocator_arg_t, inner_allocator_type&, Args...>::value==true, then calls

std::allocator_traits<OUTERMOST>::construct( OUTERMOST(*this),
                                             p,
                                             std::allocator_arg,
                                             inner_allocator(),
                                             std::forward<Args>(args)... );

Otherwise, std::uses_allocator<T, inner_allocator_type>::value==true (the type T uses allocators, e.g. it is a container) and if std::is_constructible<T, Args..., inner_allocator_type&>::value==true, then calls

std::allocator_traits<OUTERMOST>::construct( OUTERMOST(*this),
                                             p,
                                             std::forward<Args>(args)...,
                                             inner_allocator());

Otherwise, compilation error is issued because although std::uses_allocator<T> claimed that T is allocator-aware, it lacks either form of allocator-accepting constructors.

This overload participates in overload resolution only if U is not a specialization of std::pair.

2) First, if either T1 or T2 is allocator-aware, modifies the tuples x and y to include the appropriate inner allocator, resulting in the two new tuples xprime and yprime, according to the following three rules:

2a) if T1 is not allocator-aware (std::uses_allocator<T1, inner_allocator_type>::value==false, then xprime is x, unmodified. (it is also required that std::is_constructible<T1, Args1...>::value==true)

2b) if T1 is allocator-aware (std::uses_allocator<T1, inner_allocator_type>::value==true), and its constructor takes an allocator tag (std::is_constructible<T1, std::allocator_arg_t, inner_allocator_type&, Args1...>::value==true, then xprime is std::tuple_cat( std::tuple<std::allocator_arg_t, inner_allocator_type&>( std::allocator_arg,
                                                                         inner_allocator()
                                                                       ), std::move(x))

2c) if T1 is allocator-aware (std::uses_allocator<T1, inner_allocator_type>::value==true), and its constructor takes the allocator as the last argument (std::is_constructible<T1, Args1..., inner_allocator_type&>::value==true), then xprime is std::tuple_cat(std::move(x), std::tuple<inner_allocator_type&>(inner_allocator())).

Same rules apply to T2 and the replacement of y with yprime

Once xprime and yprime are constructed (this also requires that all types in Args1... and Args2... are Template:concept), constructs the pair p in allocated storage by calling

std::allocator_traits<OUTERMOST>::construct( OUTERMOST(*this),
                                             p,
                                             std::piecewise_construct,
                                             std::move(xprime),
                                             std::move(yprime));


3) Equivalent to construct(p, std::piecewise_construct, std::tuple<>(), std::tuple<>()), that is, passes the inner allocator on to the pair's member types if they accept them.

4) Equivalent to

construct(p, std::piecewise_construct, std::forward_as_tuple(std::forward<U>(x)),
                                           std::forward_as_tuple(std::forward<V>(y)))

5) Equivalent to

construct(p, std::piecewise_construct, std::forward_as_tuple(xy.first),
                                           std::forward_as_tuple(xy.second))

6) Equivalent to

construct(p, std::piecewise_construct, std::forward_as_tuple(std::forward<U>(xy.first)),
                                           std::forward_as_tuple(std::forward<V>(xy.second)))

Contents

Parameters

p - pointer to allocated, but not initialized storage
args... - the constructor arguments to pass to the constructor of T
x - the constructor arguments to pass to the constructor of T1
y - the constructor arguments to pass to the constructor of T2
xy - the pair whose two members are the constructor arguments for T1 and T2

Return value

(none)

Notes

This function is called (through std::allocator_traits) by any allocator-aware object, such as std::vector, that was given a std::scoped_allocator_adaptor as the allocator to use. Since inner_allocator is itself an instance of std::scoped_allocator_adaptor, this function will also be called when the allocator-aware objects constructed through this function start constructing their own members.

Defect reports

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

DR Applied to Behavior as published Correct behavior
LWG 2975 C++11 first overload is mistakenly used for pair construction in some cases constrained to not accept pairs

See also

[static]
constructs an object in the allocated storage
(function template) [edit]
(until C++20)
constructs an object in allocated storage
(public member function of std::allocator<T>) [edit]