feedc0de/boost_unordered
1
0 Fork 0
forked from boostorg/unordered
Code Pull Requests Activity

Merge unordred changes.

Browse Source 
Merged revisions 56441,56461,56468,56557-56562 via svnmerge from 
https://svn.boost.org/svn/boost/trunk

........
  r56441 | danieljames | 2009-09-27 20:12:04 +0100 (Sun, 27 Sep 2009) | 1 line
  
  Try supporting reference parameters in pairs. Probably not required.
........
  r56461 | danieljames | 2009-09-29 00:06:03 +0100 (Tue, 29 Sep 2009) | 1 line
  
  Remove the optimization for std::pair with a key reference. It'll be too much hassle to get a very unusual use case to work on all compilers.
........
  r56468 | danieljames | 2009-09-29 08:46:44 +0100 (Tue, 29 Sep 2009) | 1 line
  
  Just remove the test since the test itself doesn't work on most compilers.
........
  r56557 | danieljames | 2009-10-03 17:40:26 +0100 (Sat, 03 Oct 2009) | 1 line
  
  Fix the iterator category.
........
  r56558 | danieljames | 2009-10-03 17:40:53 +0100 (Sat, 03 Oct 2009) | 2 lines
  
  Update reference docs to latest version of draft standard and fill in
  some missing details.
........
  r56559 | danieljames | 2009-10-03 17:41:11 +0100 (Sat, 03 Oct 2009) | 1 line
  
  Stricter insert exception tests.
........
  r56560 | danieljames | 2009-10-03 17:41:32 +0100 (Sat, 03 Oct 2009) | 1 line
  
  Insert using initializer lists.
........
  r56561 | danieljames | 2009-10-03 17:42:00 +0100 (Sat, 03 Oct 2009) | 1 line
  
  Update the unordered rationale.
........
  r56562 | danieljames | 2009-10-03 17:42:20 +0100 (Sat, 03 Oct 2009) | 1 line
  
  Make sure inserting from a range of types other than the value type is better tested.
........


[SVN r56700]
This commit is contained in:
Daniel James committed 2009-10-10 13:52:53 +00:00
1 parent 1e7fe6a2d0
commit 3529bc00dc
11 files changed
+395 -140
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

doc/intro.qbk
+1 -1
View File
@@ -9,7 +9,7 @@
[@http://www.boost.org/doc/html/boost_tr1.html
Boost.TR1]]
[def __draft__
[@http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2691.pdf
[@http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2960.pdf
Working Draft of the C++ Standard]]
[def __hash-table__ [@http://en.wikipedia.org/wiki/Hash_table
hash table]]
doc/rationale.qbk
+30 -92
View File
@@ -5,12 +5,6 @@
[def __wang__
[@http://www.concentric.net/~Ttwang/tech/inthash.htm
Thomas Wang's article on integer hash functions]]
[def __n2345__
[@http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2345.pdf
N2345, 'Placement Insert for Containers']]
[def __n2369__
[@http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2369.pdf
the August 2007 version of the working draft standard]]
[section:rationale Implementation Rationale]
@@ -99,105 +93,49 @@ So, this implementation uses a prime number for the hash table size.
[h2 Equality operators]
`operator==` and `operator!=` are not included in the standard, but I've
added them as I think they could be useful and can be efficiently
implemented. They are specified
differently to the standard associative containers, comparing keys
using the equality predicate rather than `operator==`. This is inconsistent
with the other containers but it is probably closer to user's expectations.
added them as I think they could be useful and can be implemented
fairly efficiently. They are specified differently to the other standard
containers, comparing keys using the equality predicate rather than
`operator==`.
It's also different to the proposal
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf n2944].
which uses the equality operators for the whole of `value_type`. This
implementation just uses the key equality function for the key,
and `mapped_type`'s equality operator in `unordered_map` and
`unordered_multimap` for the mapped part of the element.
Also, in `unordered_multimap`, the mapped values for a group of elements with
equivalent keys are only considered equal if they are in the same order,
in n2944 they just need to be a permutation of each other. Since the
order of elements with equal keys is now defined to be stable, it seems to me
that their order can be considered part of the container's value.
[h2 Active Issues and Proposals]
[h3 Removing unused allocator functions]
[h3 C++0x allocators]
In
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html
N2257, removing unused allocator functions],
Matt Austern suggests removing the `construct`, `destroy` and `address` member
functions - all of which Boost.Unordered calls. Changing this will simplify the
implementation, as well as make supporting `emplace` easier, but means that the
containers won't support allocators which require these methods to be called.
Detlef Vollmann opposed this change in
[@http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2339.htm N2339].
Recent drafts have included an overhaul of the allocators, but this was
dependent on concepts which are no longer in the standard.
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2946.pdf n2946]
attempts to respecify them without concepts. I'll try to implement this (or
an appropriate later version) in a future version of boost, possibly changed
a little to accomodate non-C++0x compilers.
[h3 Swapping containers with unequal allocators]
It isn't clear how to swap containers when their allocators aren't equal.
This is
[@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431
Issue 431: Swapping containers with unequal allocators].
Howard Hinnant wrote about this in
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html N1599]
and suggested swapping both the allocators and the containers' contents.
But the committee have now decided that `swap` should do a fast swap if the
allocator is Swappable and a slow swap using copy construction otherwise. To
make this distinction requires concepts.
In
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2387.pdf
N2387, Omnibus Allocator Fix-up Proposals],
Pablo Halpern suggests that there are actually two distinct allocator models,
"Moves with Value" and "Scoped" which behave differently:
[:
When allocators are allowed to have state, it is necessary to have a model for
determining from where an object obtains its allocator. We’ve identified two such
models: the “Moves with Value” allocator model and the “Scoped” allocator model.
In the “Moves with Value” allocator model, the copy constructor of an allocator-aware
class will copy both the value and the allocator from its argument. This is the model
specified in the C++03 standard. With this model, inserting an object into a container
usually causes the new container item to copy the allocator from the object that was
inserted. This model can be useful in special circumstances, e.g., if the items within a
container use an allocator that is specially tuned to the item’s type.
In the “Scoped” allocator model, the allocator used to construct an object is determined
by the context of that object, much like a storage class. With this model, inserting an
object into a container causes the new container item to use the same allocator as the
container. To avoid allocators being used in the wrong context, the allocator is never
copied during copy or move construction. Thus, it is possible using this model to use
allocators based on short-lived resources without fear that an object will transfer its
allocator to a copy that might outlive the (shared) allocator resource. This model is
reasonably safe and generally useful on a large scale. There was strong support in the
2005 Tremblant meeting for pursuing an allocator model that propagates allocators
from container to contained objects.
]
With these models the choice becomes clearer:
[:
I introduced the “Moves with Value” allocator model and the
“Scoped” allocator model. In the former case, the allocator is copied when the container
is copy-constructed. In the latter case it is not. Swapping the allocators is the right thing
to do if the containers conform to the “Moves with Value” allocator model and
absolutely the wrong thing to do if the containers conform to the “Scoped” allocator
model. With the two allocator models well-defined, the desired behavior becomes clear.
]
The proposal is that allocators are swapped if the allocator follows the
"Moves with Value" model and the allocator is swappable. Otherwise a slow swap
is used. Since containers currently only support the "Moves with Value" model
this is consistent with the committee's current recommendation (although it
suggests using a trait to detect if the allocator is swappable rather than a
concept).
Since there is currently neither have a swappable trait or concept for
allocators this implementation always performs a slow swap.
Issue 431: Swapping containers with unequal allocators]. This has been resolved
with the new allocator specification, so this should be fixed when
support is added.
[h3 Are insert and erase stable for unordered_multiset and unordered_multimap?]
It is not specified if `unordered_multiset` and `unordered_multimap` preserve the order
It wan't specified if `unordered_multiset` and `unordered_multimap` preserve the order
of elements with equivalent keys (i.e. if they're stable under `insert` and `erase`).
This is [@http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518 issue 581].
The current proposal is that insert, erase and rehash are stable - so they are here.
(Update: during the release of this version, this requirement was added to
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf
the lastest working draft]).
[h3 const_local_iterator cbegin, cend missing from TR1]
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2684.html#691
Issue 691] is that `cbegin` and `cend` are missing for local iterators.
The current resolution is that they'll be added, so I've added them.
Since [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf
n2691] it's been specified that they do and this implementation follows that.
[endsect]
doc/ref.xml
+244 -16
View File
@@ -23,8 +23,10 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
An unordered associative container that stores unique values.
</simpara></purpose>
<description>
<para>For the normative reference see chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">the working draft of the C++ standard [n2691].</ulink></para>
<para>Based on chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">the working draft of the C++ standard [n2960]</ulink>.
But without the updated rules for allocators.
</para>
<para><emphasis role="bold">Template Parameters</emphasis>
<informaltable>
<tgroup cols="2">
@@ -93,7 +95,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A constant iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
<para>Convertible to <type>const_iterator</type>.</para>
</description>
</typedef>
@@ -101,7 +103,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A constant iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
</description>
</typedef>
<typedef name="local_iterator">
@@ -180,6 +182,26 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The copy constructor. Copies the contained elements, hash function, predicate, maximum load factor and allocator.</para>
</description>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</constructor>
<constructor>
<parameter>
<paramtype>unordered_set &amp;&amp;</paramtype>
</parameter>
<description>
<para>The move constructor.</para>
</description>
<notes>
<para>This is emulated on compilers without rvalue references.</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</constructor>
<constructor specifiers="explicit">
<parameter name="a">
@@ -201,6 +223,9 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
</description>
</constructor>
<destructor>
<notes>
<para>The destructor is applied to every element, and all memory is deallocated</para>
</notes>
</destructor>
<method name="operator=">
<parameter>
@@ -210,6 +235,38 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The assignment operator. Copies the contained elements, hash function, predicate and maximum load factor but not the allocator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_set)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</method>
<method name="operator=">
<parameter>
<paramtype>unordered_set &amp;&amp;</paramtype>
</parameter>
<type>unordered_set&amp;</type>
<description>
<para>The move assignment operator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_set)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</method>
<method name="get_allocator" cv="const">
<type>allocator_type</type>
@@ -761,8 +818,10 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
An unordered associative container that stores values. The same key can be stored multiple times.
</simpara></purpose>
<description>
<para>For the normative reference see chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">the working draft of the C++ standard [n2691].</ulink></para>
<para>Based on chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">the working draft of the C++ standard [n2960]</ulink>.
But without the updated rules for allocators.
</para>
<para><emphasis role="bold">Template Parameters</emphasis>
<informaltable>
<tgroup cols="2">
@@ -831,7 +890,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A constant iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
<para>Convertible to <type>const_iterator</type>.</para>
</description>
</typedef>
@@ -839,7 +898,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A constant iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
</description>
</typedef>
<typedef name="local_iterator">
@@ -918,6 +977,26 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The copy constructor. Copies the contained elements, hash function, predicate, maximum load factor and allocator.</para>
</description>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</constructor>
<constructor>
<parameter>
<paramtype>unordered_multiset &amp;&amp;</paramtype>
</parameter>
<description>
<para>The move constructor.</para>
</description>
<notes>
<para>This is emulated on compilers without rvalue references.</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</constructor>
<constructor specifiers="explicit">
<parameter name="a">
@@ -939,6 +1018,9 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
</description>
</constructor>
<destructor>
<notes>
<para>The destructor is applied to every element, and all memory is deallocated</para>
</notes>
</destructor>
<method name="operator=">
<parameter>
@@ -948,6 +1030,38 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The assignment operator. Copies the contained elements, hash function, predicate and maximum load factor but not the allocator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_multiset)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</method>
<method name="operator=">
<parameter>
<paramtype>unordered_multiset &amp;&amp;</paramtype>
</parameter>
<type>unordered_multiset&amp;</type>
<description>
<para>The move assignment operator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_multiset)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</method>
<method name="get_allocator" cv="const">
<type>allocator_type</type>
@@ -1503,8 +1617,10 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
An unordered associative container that associates unique keys with another value.
</simpara></purpose>
<description>
<para>For the normative reference see chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">the working draft of the C++ standard [n2691].</ulink></para>
<para>Based on chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">the working draft of the C++ standard [n2960]</ulink>.
But without the updated rules for allocators.
</para>
<para><emphasis role="bold">Template Parameters</emphasis>
<informaltable>
<tgroup cols="2">
@@ -1579,7 +1695,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
<para>Convertible to <type>const_iterator</type>.</para>
</description>
</typedef>
@@ -1587,7 +1703,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A constant iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
</description>
</typedef>
<typedef name="local_iterator">
@@ -1666,6 +1782,26 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The copy constructor. Copies the contained elements, hash function, predicate, maximum load factor and allocator.</para>
</description>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</constructor>
<constructor>
<parameter>
<paramtype>unordered_map &amp;&amp;</paramtype>
</parameter>
<description>
<para>The move constructor.</para>
</description>
<notes>
<para>This is emulated on compilers without rvalue references.</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</constructor>
<constructor specifiers="explicit">
<parameter name="a">
@@ -1687,6 +1823,9 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
</description>
</constructor>
<destructor>
<notes>
<para>The destructor is applied to every element, and all memory is deallocated</para>
</notes>
</destructor>
<method name="operator=">
<parameter>
@@ -1696,6 +1835,38 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The assignment operator. Copies the contained elements, hash function, predicate and maximum load factor but not the allocator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_map)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</method>
<method name="operator=">
<parameter>
<paramtype>unordered_map &amp;&amp;</paramtype>
</parameter>
<type>unordered_map&amp;</type>
<description>
<para>The move assignment operator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_map)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</method>
<method name="get_allocator" cv="const">
<type>allocator_type</type>
@@ -2290,8 +2461,10 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
An unordered associative container that associates keys with another value. The same key can be stored multiple times.
</simpara></purpose>
<description>
<para>For the normative reference see chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">the working draft of the C++ standard [n2691].</ulink></para>
<para>Based on chapter 23 of
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">the working draft of the C++ standard [n2960]</ulink>.
But without the updated rules for allocators.
</para>
<para><emphasis role="bold">Template Parameters</emphasis>
<informaltable>
<tgroup cols="2">
@@ -2366,7 +2539,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
<para>Convertible to <type>const_iterator</type>.</para>
</description>
</typedef>
@@ -2374,7 +2547,7 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<type><emphasis>implementation-defined</emphasis></type>
<description>
<para>A constant iterator whose value type is <type>value_type</type>. </para>
<para>Any iterator category except output iterator.</para>
<para>The iterator category is at least a forward iterator.</para>
</description>
</typedef>
<typedef name="local_iterator">
@@ -2453,6 +2626,26 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The copy constructor. Copies the contained elements, hash function, predicate, maximum load factor and allocator.</para>
</description>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</constructor>
<constructor>
<parameter>
<paramtype>unordered_multimap &amp;&amp;</paramtype>
</parameter>
<description>
<para>The move constructor.</para>
</description>
<notes>
<para>This is emulated on compilers without rvalue references.</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</constructor>
<constructor specifiers="explicit">
<parameter name="a">
@@ -2474,6 +2667,9 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
</description>
</constructor>
<destructor>
<notes>
<para>The destructor is applied to every element, and all memory is deallocated</para>
</notes>
</destructor>
<method name="operator=">
<parameter>
@@ -2483,6 +2679,38 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
<description>
<para>The assignment operator. Copies the contained elements, hash function, predicate and maximum load factor but not the allocator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_multimap)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para><code>value_type</code> is copy constructible</para>
</requires>
</method>
<method name="operator=">
<parameter>
<paramtype>unordered_multimap &amp;&amp;</paramtype>
</parameter>
<type>unordered_multimap&amp;</type>
<description>
<para>The move assignment operator.</para>
</description>
<notes>
<para>
On compilers without rvalue references, there is a single assignment
operator with the signature <code>operator=(unordered_multimap)</code>
in order to emulate move semantics.
</para>
</notes>
<requires>
<para>
<code>value_type</code> is move constructible.
(TODO: This is not actually required in this implementation).
</para>
</requires>
</method>
<method name="get_allocator" cv="const">
<type>allocator_type</type>