maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/include/__hash_table

2454 lines
83 KiB
Plaintext
Raw Normal View History

libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
// -*- C++ -*-
//===----------------------------------------------------------------------===//
//
Wiped out some non-ascii characters that snuck into the copyright. llvm-svn: 103516
2010-05-12 05:36:01 +08:00
// The LLVM Compiler Infrastructure
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
//
license change llvm-svn: 119395
2010-11-17 06:09:02 +08:00
// This file is dual licensed under the MIT and the University of Illinois Open
// Source Licenses. See LICENSE.TXT for details.
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
//
//===----------------------------------------------------------------------===//
#ifndef _LIBCPP__HASH_TABLE
#define _LIBCPP__HASH_TABLE
#include <__config>
#include <initializer_list>
#include <memory>
#include <iterator>
#include <algorithm>
#include <cmath>
Add protection from min/max macros llvm-svn: 145407
2011-11-30 00:45:27 +08:00
#include <__undef_min_max>
Handle function name conflicts in _LIBCPP_MSVCRT mode Visual Studio's SAL extension uses a macro named __deallocate. This macro is used pervasively, and gets included through various different ways. This conflicts with the similarly named interfaces in libc++. Introduce a undef header similar to __undef_min_max to handle this. This fixes a number of errors due to the macro replacing the function name. llvm-svn: 229162
2015-02-14 06:15:32 +08:00
#include <__undef___deallocate>
Add protection from min/max macros llvm-svn: 145407
2011-11-30 00:45:27 +08:00
NFC. Move definition of _LIBCPP_ASSERT into __debug header and remove external include guards. Things done in this patch: 1. Make __debug include __config since it uses macros from it. 2. The current method of defining _LIBCPP_ASSERT is prone to redefinitions. Move the null _LIBCPP_ASSERT definition into the __debug header to prevent this. 3. Remove external <__debug> include gaurds. <__debug> guards almost all of its contents internally. There is no reason to be doing it externally. This patch should not change any functionality. llvm-svn: 215332
2014-08-11 07:53:08 +08:00
#include <__debug>
Ok, 3 major changes for debug mode in one commit: 1. I had been detecting and trapping iterator == and \!= among iterators in different containers as an error. But the trapping itself is actually an error. Consider: #include <iostream> #include <vector> #include <algorithm> template <class C> void display(const C& c) { std::cout << "{"; bool first = true; for (const auto& x : c) { if (\!first) std::cout << ", "; first = false; std::cout << x; } std::cout << "}\n"; } int main() { typedef std::vector<int> V; V v1 = {1, 3, 5}; V v2 = {2, 4, 6}; display(v1); display(v2); V::iterator i = std::find(v1.begin(), v1.end(), 1); V::iterator j = std::find(v2.begin(), v2.end(), 2); if (*i == *j) i = j; // perfectly legal // ... if (i \!= j) // the only way to check v2.push_back(*i); display(v1); display(v2); } It is legal to assign an iterator from one container to another of the same type. This is required to work. One might want to test whether or not such an assignment had been made. The way one performs such a check is using the iterator's ==, \!= operator. This is a logical and necessary function and does not constitute an error. 2. I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined. This caused a problem in several of the libc++ tests. Fixed. 3. There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that std::basic_string is inoperable. std::basic_string uses __wrap_iterator to implement its iterators. __wrap_iterator has been rigged up in debug mode to support vector. But string hasn't been rigged up yet. This means that one gets false positives when using std::string in debug mode. I've upped std::string's priority in www/debug_mode.html. llvm-svn: 187636
2013-08-02 08:26:35 +08:00
Windows support by Ruben Van Boxem. llvm-svn: 142235
2011-10-18 04:05:10 +08:00
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
#pragma GCC system_header
Windows support by Ruben Van Boxem. llvm-svn: 142235
2011-10-18 04:05:10 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
_LIBCPP_BEGIN_NAMESPACE_STD
No functionality change at this time. I've split _LIBCPP_VISIBLE up into two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute. llvm-svn: 176593
2013-03-07 07:30:19 +08:00
_LIBCPP_FUNC_VIS
Provide names for template and function parameters in forward declarations. The purpose is to aid automated documentation tools. llvm-svn: 133008
2011-06-15 03:58:17 +08:00
size_t __next_prime(size_t __n);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _NodePtr>
struct __hash_node_base
{
typedef __hash_node_base __first_node;
Fixed two problems found by Chris Jefferson: Made operator>> for char consistent with gcc. Opened an LWG issue on this one. 2) Renamed some private typedefs which are causing boost grief. llvm-svn: 126576
2011-02-28 02:02:02 +08:00
_NodePtr __next_;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY __hash_node_base() _NOEXCEPT : __next_(nullptr) {}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
};
template <class _Tp, class _VoidPtr>
struct __hash_node
: public __hash_node_base
<
typename pointer_traits<_VoidPtr>::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<__hash_node<_Tp, _VoidPtr> >
#else
rebind<__hash_node<_Tp, _VoidPtr> >::other
#endif
>
{
typedef _Tp value_type;
size_t __hash_;
value_type __value_;
};
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
inline _LIBCPP_INLINE_VISIBILITY
bool
Rename pow2 functions in __hash_table to reflect that they are hash specific llvm-svn: 227866
2015-02-03 05:31:48 +08:00
__is_hash_power2(size_t __bc)
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
{
return __bc > 2 && !(__bc & (__bc - 1));
}
inline _LIBCPP_INLINE_VISIBILITY
size_t
__constrain_hash(size_t __h, size_t __bc)
{
return !(__bc & (__bc - 1)) ? __h & (__bc - 1) : __h % __bc;
}
inline _LIBCPP_INLINE_VISIBILITY
size_t
Rename pow2 functions in __hash_table to reflect that they are hash specific llvm-svn: 227866
2015-02-03 05:31:48 +08:00
__next_hash_pow2(size_t __n)
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
{
return size_t(1) << (std::numeric_limits<size_t>::digits - __clz(__n-1));
}
Provide names for template and function parameters in forward declarations. The purpose is to aid automated documentation tools. llvm-svn: 133008
2011-06-15 03:58:17 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc> class __hash_table;
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
template <class _ConstNodePtr> class _LIBCPP_TYPE_VIS_ONLY __hash_const_iterator;
template <class _HashIterator> class _LIBCPP_TYPE_VIS_ONLY __hash_map_iterator;
template <class _HashIterator> class _LIBCPP_TYPE_VIS_ONLY __hash_map_const_iterator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _NodePtr>
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
class _LIBCPP_TYPE_VIS_ONLY __hash_iterator
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
typedef _NodePtr __node_pointer;
__node_pointer __node_;
public:
typedef forward_iterator_tag iterator_category;
typedef typename pointer_traits<__node_pointer>::element_type::value_type value_type;
typedef typename pointer_traits<__node_pointer>::difference_type difference_type;
typedef value_type& reference;
typedef typename pointer_traits<__node_pointer>::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<value_type>
#else
rebind<value_type>::other
#endif
pointer;
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
_LIBCPP_INLINE_VISIBILITY __hash_iterator() _NOEXCEPT
N3644 support for <unordered_set> and <unordered_map> llvm-svn: 187915
2013-08-08 05:30:44 +08:00
#if _LIBCPP_STD_VER > 11
: __node_(nullptr)
#endif
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__insert_i(this);
#endif
}
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_iterator(const __hash_iterator& __i)
: __node_(__i.__node_)
{
__get_db()->__iterator_copy(this, &__i);
}
_LIBCPP_INLINE_VISIBILITY
~__hash_iterator()
{
__get_db()->__erase_i(this);
}
_LIBCPP_INLINE_VISIBILITY
__hash_iterator& operator=(const __hash_iterator& __i)
{
if (this != &__i)
{
__get_db()->__iterator_copy(this, &__i);
__node_ = __i.__node_;
}
return *this;
}
#endif // _LIBCPP_DEBUG_LEVEL >= 2
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
reference operator*() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container iterator");
#endif
return __node_->__value_;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
pointer operator->() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container iterator");
#endif
return pointer_traits<pointer>::pointer_to(__node_->__value_);
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_iterator& operator++()
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to increment non-incrementable unordered container iterator");
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_ = __node_->__next_;
return *this;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_iterator operator++(int)
{
__hash_iterator __t(*this);
++(*this);
return __t;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator==(const __hash_iterator& __x, const __hash_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
return __x.__node_ == __y.__node_;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator!=(const __hash_iterator& __x, const __hash_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{return !(__x == __y);}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
private:
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_iterator(__node_pointer __node, const void* __c) _NOEXCEPT
: __node_(__node)
{
__get_db()->__insert_ic(this, __c);
}
#else
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_iterator(__node_pointer __node) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __node_(__node)
{}
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class, class, class, class> friend class __hash_table;
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
template <class> friend class _LIBCPP_TYPE_VIS_ONLY __hash_const_iterator;
template <class> friend class _LIBCPP_TYPE_VIS_ONLY __hash_map_iterator;
template <class, class, class, class, class> friend class _LIBCPP_TYPE_VIS_ONLY unordered_map;
template <class, class, class, class, class> friend class _LIBCPP_TYPE_VIS_ONLY unordered_multimap;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
};
template <class _ConstNodePtr>
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
class _LIBCPP_TYPE_VIS_ONLY __hash_const_iterator
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
typedef _ConstNodePtr __node_pointer;
__node_pointer __node_;
typedef typename remove_const<
typename pointer_traits<__node_pointer>::element_type
>::type __node;
public:
typedef forward_iterator_tag iterator_category;
typedef typename __node::value_type value_type;
typedef typename pointer_traits<__node_pointer>::difference_type difference_type;
typedef const value_type& reference;
typedef typename pointer_traits<__node_pointer>::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<const value_type>
#else
rebind<const value_type>::other
#endif
pointer;
typedef typename pointer_traits<__node_pointer>::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<__node>
#else
rebind<__node>::other
#endif
__non_const_node_pointer;
typedef __hash_iterator<__non_const_node_pointer> __non_const_iterator;
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
_LIBCPP_INLINE_VISIBILITY __hash_const_iterator() _NOEXCEPT
N3644 support for <unordered_set> and <unordered_map> llvm-svn: 187915
2013-08-08 05:30:44 +08:00
#if _LIBCPP_STD_VER > 11
: __node_(nullptr)
#endif
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__insert_i(this);
#endif
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_const_iterator(const __non_const_iterator& __x) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __node_(__x.__node_)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__iterator_copy(this, &__x);
#endif
}
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_const_iterator(const __hash_const_iterator& __i)
: __node_(__i.__node_)
{
__get_db()->__iterator_copy(this, &__i);
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
~__hash_const_iterator()
{
__get_db()->__erase_i(this);
}
_LIBCPP_INLINE_VISIBILITY
__hash_const_iterator& operator=(const __hash_const_iterator& __i)
{
if (this != &__i)
{
__get_db()->__iterator_copy(this, &__i);
__node_ = __i.__node_;
}
return *this;
}
#endif // _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
reference operator*() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container const_iterator");
#endif
return __node_->__value_;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
pointer operator->() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container const_iterator");
#endif
return pointer_traits<pointer>::pointer_to(__node_->__value_);
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_const_iterator& operator++()
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to increment non-incrementable unordered container const_iterator");
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_ = __node_->__next_;
return *this;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_const_iterator operator++(int)
{
__hash_const_iterator __t(*this);
++(*this);
return __t;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator==(const __hash_const_iterator& __x, const __hash_const_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
return __x.__node_ == __y.__node_;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator!=(const __hash_const_iterator& __x, const __hash_const_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{return !(__x == __y);}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
private:
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_const_iterator(__node_pointer __node, const void* __c) _NOEXCEPT
: __node_(__node)
{
__get_db()->__insert_ic(this, __c);
}
#else
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_const_iterator(__node_pointer __node) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __node_(__node)
{}
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class, class, class, class> friend class __hash_table;
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
template <class> friend class _LIBCPP_TYPE_VIS_ONLY __hash_map_const_iterator;
template <class, class, class, class, class> friend class _LIBCPP_TYPE_VIS_ONLY unordered_map;
template <class, class, class, class, class> friend class _LIBCPP_TYPE_VIS_ONLY unordered_multimap;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
};
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
template <class _ConstNodePtr> class _LIBCPP_TYPE_VIS_ONLY __hash_const_local_iterator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _NodePtr>
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
class _LIBCPP_TYPE_VIS_ONLY __hash_local_iterator
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
typedef _NodePtr __node_pointer;
__node_pointer __node_;
size_t __bucket_;
size_t __bucket_count_;
typedef pointer_traits<__node_pointer> __pointer_traits;
public:
typedef forward_iterator_tag iterator_category;
typedef typename __pointer_traits::element_type::value_type value_type;
typedef typename __pointer_traits::difference_type difference_type;
typedef value_type& reference;
typedef typename __pointer_traits::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<value_type>
#else
rebind<value_type>::other
#endif
pointer;
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
_LIBCPP_INLINE_VISIBILITY __hash_local_iterator() _NOEXCEPT
{
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__insert_i(this);
#endif
}
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_local_iterator(const __hash_local_iterator& __i)
: __node_(__i.__node_),
__bucket_(__i.__bucket_),
__bucket_count_(__i.__bucket_count_)
{
__get_db()->__iterator_copy(this, &__i);
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
~__hash_local_iterator()
{
__get_db()->__erase_i(this);
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
__hash_local_iterator& operator=(const __hash_local_iterator& __i)
{
if (this != &__i)
{
__get_db()->__iterator_copy(this, &__i);
__node_ = __i.__node_;
__bucket_ = __i.__bucket_;
__bucket_count_ = __i.__bucket_count_;
}
return *this;
}
#endif // _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
reference operator*() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container local_iterator");
#endif
return __node_->__value_;
}
_LIBCPP_INLINE_VISIBILITY
pointer operator->() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container local_iterator");
#endif
return pointer_traits<pointer>::pointer_to(__node_->__value_);
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_local_iterator& operator++()
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to increment non-incrementable unordered container local_iterator");
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_ = __node_->__next_;
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
if (__node_ != nullptr && __constrain_hash(__node_->__hash_, __bucket_count_) != __bucket_)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_ = nullptr;
return *this;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_local_iterator operator++(int)
{
__hash_local_iterator __t(*this);
++(*this);
return __t;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator==(const __hash_local_iterator& __x, const __hash_local_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
return __x.__node_ == __y.__node_;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator!=(const __hash_local_iterator& __x, const __hash_local_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{return !(__x == __y);}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
private:
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_local_iterator(__node_pointer __node, size_t __bucket,
size_t __bucket_count, const void* __c) _NOEXCEPT
: __node_(__node),
__bucket_(__bucket),
__bucket_count_(__bucket_count)
{
__get_db()->__insert_ic(this, __c);
if (__node_ != nullptr)
__node_ = __node_->__next_;
}
#else
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_local_iterator(__node_pointer __node, size_t __bucket,
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
size_t __bucket_count) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __node_(__node),
__bucket_(__bucket),
__bucket_count_(__bucket_count)
{
if (__node_ != nullptr)
__node_ = __node_->__next_;
}
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class, class, class, class> friend class __hash_table;
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
template <class> friend class _LIBCPP_TYPE_VIS_ONLY __hash_const_local_iterator;
template <class> friend class _LIBCPP_TYPE_VIS_ONLY __hash_map_iterator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
};
template <class _ConstNodePtr>
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
class _LIBCPP_TYPE_VIS_ONLY __hash_const_local_iterator
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
typedef _ConstNodePtr __node_pointer;
__node_pointer __node_;
size_t __bucket_;
size_t __bucket_count_;
typedef pointer_traits<__node_pointer> __pointer_traits;
typedef typename __pointer_traits::element_type __node;
typedef typename remove_const<__node>::type __non_const_node;
typedef typename pointer_traits<__node_pointer>::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<__non_const_node>
#else
rebind<__non_const_node>::other
#endif
__non_const_node_pointer;
typedef __hash_local_iterator<__non_const_node_pointer>
__non_const_iterator;
public:
typedef forward_iterator_tag iterator_category;
typedef typename remove_const<
typename __pointer_traits::element_type::value_type
>::type value_type;
typedef typename __pointer_traits::difference_type difference_type;
typedef const value_type& reference;
typedef typename __pointer_traits::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<const value_type>
#else
rebind<const value_type>::other
#endif
pointer;
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
_LIBCPP_INLINE_VISIBILITY __hash_const_local_iterator() _NOEXCEPT
{
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__insert_i(this);
#endif
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_const_local_iterator(const __non_const_iterator& __x) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __node_(__x.__node_),
__bucket_(__x.__bucket_),
__bucket_count_(__x.__bucket_count_)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__iterator_copy(this, &__x);
#endif
}
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_const_local_iterator(const __hash_const_local_iterator& __i)
: __node_(__i.__node_),
__bucket_(__i.__bucket_),
__bucket_count_(__i.__bucket_count_)
{
__get_db()->__iterator_copy(this, &__i);
}
_LIBCPP_INLINE_VISIBILITY
~__hash_const_local_iterator()
{
__get_db()->__erase_i(this);
}
_LIBCPP_INLINE_VISIBILITY
__hash_const_local_iterator& operator=(const __hash_const_local_iterator& __i)
{
if (this != &__i)
{
__get_db()->__iterator_copy(this, &__i);
__node_ = __i.__node_;
__bucket_ = __i.__bucket_;
__bucket_count_ = __i.__bucket_count_;
}
return *this;
}
#endif // _LIBCPP_DEBUG_LEVEL >= 2
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
reference operator*() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container const_local_iterator");
#endif
return __node_->__value_;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
pointer operator->() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable unordered container const_local_iterator");
#endif
return pointer_traits<pointer>::pointer_to(__node_->__value_);
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_const_local_iterator& operator++()
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to increment non-incrementable unordered container const_local_iterator");
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_ = __node_->__next_;
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
if (__node_ != nullptr && __constrain_hash(__node_->__hash_, __bucket_count_) != __bucket_)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_ = nullptr;
return *this;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_const_local_iterator operator++(int)
{
__hash_const_local_iterator __t(*this);
++(*this);
return __t;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator==(const __hash_const_local_iterator& __x, const __hash_const_local_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{
return __x.__node_ == __y.__node_;
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator!=(const __hash_const_local_iterator& __x, const __hash_const_local_iterator& __y)
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
{return !(__x == __y);}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
private:
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
__hash_const_local_iterator(__node_pointer __node, size_t __bucket,
size_t __bucket_count, const void* __c) _NOEXCEPT
: __node_(__node),
__bucket_(__bucket),
__bucket_count_(__bucket_count)
{
__get_db()->__insert_ic(this, __c);
if (__node_ != nullptr)
__node_ = __node_->__next_;
}
#else
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_const_local_iterator(__node_pointer __node, size_t __bucket,
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
size_t __bucket_count) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __node_(__node),
__bucket_(__bucket),
__bucket_count_(__bucket_count)
{
if (__node_ != nullptr)
__node_ = __node_->__next_;
}
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class, class, class, class> friend class __hash_table;
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
template <class> friend class _LIBCPP_TYPE_VIS_ONLY __hash_map_const_iterator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
};
template <class _Alloc>
class __bucket_list_deallocator
{
typedef _Alloc allocator_type;
typedef allocator_traits<allocator_type> __alloc_traits;
typedef typename __alloc_traits::size_type size_type;
__compressed_pair<size_type, allocator_type> __data_;
public:
typedef typename __alloc_traits::pointer pointer;
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__bucket_list_deallocator()
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(is_nothrow_default_constructible<allocator_type>::value)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __data_(0) {}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__bucket_list_deallocator(const allocator_type& __a, size_type __size)
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(is_nothrow_copy_constructible<allocator_type>::value)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __data_(__size, __a) {}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__bucket_list_deallocator(__bucket_list_deallocator&& __x)
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(is_nothrow_move_constructible<allocator_type>::value)
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
: __data_(_VSTD::move(__x.__data_))
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
__x.size() = 0;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
size_type& size() _NOEXCEPT {return __data_.first();}
_LIBCPP_INLINE_VISIBILITY
size_type size() const _NOEXCEPT {return __data_.first();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
allocator_type& __alloc() _NOEXCEPT {return __data_.second();}
_LIBCPP_INLINE_VISIBILITY
const allocator_type& __alloc() const _NOEXCEPT {return __data_.second();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
void operator()(pointer __p) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
__alloc_traits::deallocate(__alloc(), __p, size());
}
};
Provide names for template and function parameters in forward declarations. The purpose is to aid automated documentation tools. llvm-svn: 133008
2011-06-15 03:58:17 +08:00
template <class _Alloc> class __hash_map_node_destructor;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Alloc>
class __hash_node_destructor
{
typedef _Alloc allocator_type;
typedef allocator_traits<allocator_type> __alloc_traits;
typedef typename __alloc_traits::value_type::value_type value_type;
public:
typedef typename __alloc_traits::pointer pointer;
private:
allocator_type& __na_;
__hash_node_destructor& operator=(const __hash_node_destructor&);
public:
bool __value_constructed;
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Fixed PR10507 (http://llvm.org/bugs/show_bug.cgi?id=10507) llvm-svn: 136595
2011-08-01 01:04:30 +08:00
explicit __hash_node_destructor(allocator_type& __na,
bool __constructed = false) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __na_(__na),
Fixed PR10507 (http://llvm.org/bugs/show_bug.cgi?id=10507) llvm-svn: 136595
2011-08-01 01:04:30 +08:00
__value_constructed(__constructed)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
void operator()(pointer __p) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
if (__value_constructed)
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__alloc_traits::destroy(__na_, _VSTD::addressof(__p->__value_));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
if (__p)
__alloc_traits::deallocate(__na_, __p, 1);
}
template <class> friend class __hash_map_node_destructor;
};
template <class _Tp, class _Hash, class _Equal, class _Alloc>
class __hash_table
{
public:
typedef _Tp value_type;
typedef _Hash hasher;
typedef _Equal key_equal;
typedef _Alloc allocator_type;
private:
typedef allocator_traits<allocator_type> __alloc_traits;
public:
typedef value_type& reference;
typedef const value_type& const_reference;
typedef typename __alloc_traits::pointer pointer;
typedef typename __alloc_traits::const_pointer const_pointer;
typedef typename __alloc_traits::size_type size_type;
typedef typename __alloc_traits::difference_type difference_type;
public:
// Create __node
typedef __hash_node<value_type, typename __alloc_traits::void_pointer> __node;
In many places, there was an #ifdef/#else block that selected one of two implmentations of rebind_alloc based on whether or not we had template aliases. Create a helper struct to encapsulate that bit of logic, and replace all the ifdefs with uses of that struct. No functionality change intented. llvm-svn: 234296
2015-04-07 13:21:38 +08:00
typedef typename __rebind_alloc_helper<__alloc_traits, __node>::type __node_allocator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typedef allocator_traits<__node_allocator> __node_traits;
typedef typename __node_traits::pointer __node_pointer;
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
typedef typename __node_traits::pointer __node_const_pointer;
As an extension, support incomplete types in the unordered containers to match what we already do in the associative containers. llvm-svn: 146376
2011-12-13 01:26:24 +08:00
typedef __hash_node_base<__node_pointer> __first_node;
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
typedef typename pointer_traits<__node_pointer>::template
#ifndef _LIBCPP_HAS_NO_TEMPLATE_ALIASES
rebind<__first_node>
#else
rebind<__first_node>::other
#endif
__node_base_pointer;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
private:
In many places, there was an #ifdef/#else block that selected one of two implmentations of rebind_alloc based on whether or not we had template aliases. Create a helper struct to encapsulate that bit of logic, and replace all the ifdefs with uses of that struct. No functionality change intented. llvm-svn: 234296
2015-04-07 13:21:38 +08:00
typedef typename __rebind_alloc_helper<__node_traits, __node_pointer>::type __pointer_allocator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typedef __bucket_list_deallocator<__pointer_allocator> __bucket_list_deleter;
typedef unique_ptr<__node_pointer[], __bucket_list_deleter> __bucket_list;
typedef allocator_traits<__pointer_allocator> __pointer_alloc_traits;
typedef typename __bucket_list_deleter::pointer __node_pointer_pointer;
// --- Member data begin ---
__bucket_list __bucket_list_;
__compressed_pair<__first_node, __node_allocator> __p1_;
__compressed_pair<size_type, hasher> __p2_;
__compressed_pair<float, key_equal> __p3_;
// --- Member data end ---
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
size_type& size() _NOEXCEPT {return __p2_.first();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
public:
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
size_type size() const _NOEXCEPT {return __p2_.first();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
hasher& hash_function() _NOEXCEPT {return __p2_.second();}
_LIBCPP_INLINE_VISIBILITY
const hasher& hash_function() const _NOEXCEPT {return __p2_.second();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
float& max_load_factor() _NOEXCEPT {return __p3_.first();}
_LIBCPP_INLINE_VISIBILITY
float max_load_factor() const _NOEXCEPT {return __p3_.first();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
key_equal& key_eq() _NOEXCEPT {return __p3_.second();}
_LIBCPP_INLINE_VISIBILITY
const key_equal& key_eq() const _NOEXCEPT {return __p3_.second();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY
__node_allocator& __node_alloc() _NOEXCEPT {return __p1_.second();}
_LIBCPP_INLINE_VISIBILITY
const __node_allocator& __node_alloc() const _NOEXCEPT
{return __p1_.second();}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
public:
typedef __hash_iterator<__node_pointer> iterator;
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
typedef __hash_const_iterator<__node_pointer> const_iterator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typedef __hash_local_iterator<__node_pointer> local_iterator;
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
typedef __hash_const_local_iterator<__node_pointer> const_local_iterator;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table()
_NOEXCEPT_(
is_nothrow_default_constructible<__bucket_list>::value &&
is_nothrow_default_constructible<__first_node>::value &&
is_nothrow_default_constructible<__node_allocator>::value &&
is_nothrow_default_constructible<hasher>::value &&
is_nothrow_default_constructible<key_equal>::value);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_table(const hasher& __hf, const key_equal& __eql);
__hash_table(const hasher& __hf, const key_equal& __eql,
const allocator_type& __a);
explicit __hash_table(const allocator_type& __a);
__hash_table(const __hash_table& __u);
__hash_table(const __hash_table& __u, const allocator_type& __a);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table(__hash_table&& __u)
_NOEXCEPT_(
is_nothrow_move_constructible<__bucket_list>::value &&
is_nothrow_move_constructible<__first_node>::value &&
is_nothrow_move_constructible<__node_allocator>::value &&
is_nothrow_move_constructible<hasher>::value &&
is_nothrow_move_constructible<key_equal>::value);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_table(__hash_table&& __u, const allocator_type& __a);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
~__hash_table();
__hash_table& operator=(const __hash_table& __u);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table& operator=(__hash_table&& __u)
_NOEXCEPT_(
__node_traits::propagate_on_container_move_assignment::value &&
is_nothrow_move_assignable<__node_allocator>::value &&
is_nothrow_move_assignable<hasher>::value &&
is_nothrow_move_assignable<key_equal>::value);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
#endif
template <class _InputIterator>
void __assign_unique(_InputIterator __first, _InputIterator __last);
template <class _InputIterator>
void __assign_multi(_InputIterator __first, _InputIterator __last);
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
size_type max_size() const _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
return allocator_traits<__pointer_allocator>::max_size(
__bucket_list_.get_deleter().__alloc());
}
pair<iterator, bool> __node_insert_unique(__node_pointer __nd);
iterator __node_insert_multi(__node_pointer __nd);
iterator __node_insert_multi(const_iterator __p,
__node_pointer __nd);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#if !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && !defined(_LIBCPP_HAS_NO_VARIADICS)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class... _Args>
pair<iterator, bool> __emplace_unique(_Args&&... __args);
template <class... _Args>
iterator __emplace_multi(_Args&&... __args);
template <class... _Args>
iterator __emplace_hint_multi(const_iterator __p, _Args&&... __args);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && !defined(_LIBCPP_HAS_NO_VARIADICS)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
Fix PR12999 - unordered_set::insert calls operator new when no insert occurs Summary: when `unordered_set::insert(value_type&&)` was called it would be treated like `unordered_set::emplace(Args&&)` and it would allocate and construct a node before trying to insert it. This caused unnecessary allocations when the value was already in the set. This patch adds an overload to `__hash_table::__insert_unique` that specifically handles `value_type&&` more link `value_type const &`. This patch also adds a single unified insert function for values into `__hash_table` called `__insert_unique_value` that handles the cases for `__insert_unique(value_type&&)` and `__insert_unique(value_type const &)`. This patch fixes PR12999: http://llvm.org/bugs/show_bug.cgi?id=12999. Reviewers: mclow.lists, titus, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7570 llvm-svn: 239666
2015-06-13 15:18:32 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
template <class _ValueTp>
_LIBCPP_INLINE_VISIBILITY
pair<iterator, bool> __insert_unique_value(_ValueTp&& __x);
#else
_LIBCPP_INLINE_VISIBILITY
pair<iterator, bool> __insert_unique_value(const value_type& __x);
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
pair<iterator, bool> __insert_unique(const value_type& __x);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
Fix PR12999 - unordered_set::insert calls operator new when no insert occurs Summary: when `unordered_set::insert(value_type&&)` was called it would be treated like `unordered_set::emplace(Args&&)` and it would allocate and construct a node before trying to insert it. This caused unnecessary allocations when the value was already in the set. This patch adds an overload to `__hash_table::__insert_unique` that specifically handles `value_type&&` more link `value_type const &`. This patch also adds a single unified insert function for values into `__hash_table` called `__insert_unique_value` that handles the cases for `__insert_unique(value_type&&)` and `__insert_unique(value_type const &)`. This patch fixes PR12999: http://llvm.org/bugs/show_bug.cgi?id=12999. Reviewers: mclow.lists, titus, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7570 llvm-svn: 239666
2015-06-13 15:18:32 +08:00
pair<iterator, bool> __insert_unique(value_type&& __x);
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
template <class _Pp>
Fix PR12999 - unordered_set::insert calls operator new when no insert occurs Summary: when `unordered_set::insert(value_type&&)` was called it would be treated like `unordered_set::emplace(Args&&)` and it would allocate and construct a node before trying to insert it. This caused unnecessary allocations when the value was already in the set. This patch adds an overload to `__hash_table::__insert_unique` that specifically handles `value_type&&` more link `value_type const &`. This patch also adds a single unified insert function for values into `__hash_table` called `__insert_unique_value` that handles the cases for `__insert_unique(value_type&&)` and `__insert_unique(value_type const &)`. This patch fixes PR12999: http://llvm.org/bugs/show_bug.cgi?id=12999. Reviewers: mclow.lists, titus, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7570 llvm-svn: 239666
2015-06-13 15:18:32 +08:00
pair<iterator, bool> __insert_unique(_Pp&& __x);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
template <class _Pp>
iterator __insert_multi(_Pp&& __x);
template <class _Pp>
iterator __insert_multi(const_iterator __p, _Pp&& __x);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#else // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
iterator __insert_multi(const value_type& __x);
iterator __insert_multi(const_iterator __p, const value_type& __x);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
void clear() _NOEXCEPT;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
void rehash(size_type __n);
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY void reserve(size_type __n)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{rehash(static_cast<size_type>(ceil(__n / max_load_factor())));}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
size_type bucket_count() const _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
return __bucket_list_.get_deleter().size();
}
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
iterator begin() _NOEXCEPT;
iterator end() _NOEXCEPT;
const_iterator begin() const _NOEXCEPT;
const_iterator end() const _NOEXCEPT;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Key>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type bucket(const _Key& __k) const
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
{
_LIBCPP_ASSERT(bucket_count() > 0,
"unordered container::bucket(key) called when bucket_count() == 0");
return __constrain_hash(hash_function()(__k), bucket_count());
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Key>
iterator find(const _Key& __x);
template <class _Key>
const_iterator find(const _Key& __x) const;
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
typedef __hash_node_destructor<__node_allocator> _Dp;
typedef unique_ptr<__node, _Dp> __node_holder;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
iterator erase(const_iterator __p);
iterator erase(const_iterator __first, const_iterator __last);
template <class _Key>
size_type __erase_unique(const _Key& __k);
template <class _Key>
size_type __erase_multi(const _Key& __k);
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__node_holder remove(const_iterator __p) _NOEXCEPT;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Key>
size_type __count_unique(const _Key& __k) const;
template <class _Key>
size_type __count_multi(const _Key& __k) const;
template <class _Key>
pair<iterator, iterator>
__equal_range_unique(const _Key& __k);
template <class _Key>
pair<const_iterator, const_iterator>
__equal_range_unique(const _Key& __k) const;
template <class _Key>
pair<iterator, iterator>
__equal_range_multi(const _Key& __k);
template <class _Key>
pair<const_iterator, const_iterator>
__equal_range_multi(const _Key& __k) const;
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
void swap(__hash_table& __u)
Enable and fix warnings during the build. Although CMake adds warning flags, they are ignored in the libc++ headers because the headers '#pragma system header' themselves. This patch disables the system header pragma when building libc++ and fixes the warnings that arose. The warnings fixed were: 1. <memory> - anonymous structs are a GNU extension 2. <functional> - anonymous structs are a GNU extension. 3. <__hash_table> - Embedded preprocessor directives have undefined behavior. 4. <string> - Definition is missing noexcept from declaration. 5. <__std_stream> - Unused variable. llvm-svn: 242623
2015-07-19 04:40:46 +08:00
#if _LIBCPP_STD_VER <= 11
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(
Implement the first part of N4258: 'Cleaning up noexcept in the Library'. This patch deals with swapping containers, and implements a more strict noexcept specification (a conforming extension) than the standard mandates. llvm-svn: 242056
2015-07-14 04:04:56 +08:00
__is_nothrow_swappable<hasher>::value && __is_nothrow_swappable<key_equal>::value
&& (!allocator_traits<__pointer_allocator>::propagate_on_container_swap::value
|| __is_nothrow_swappable<__pointer_allocator>::value)
&& (!__node_traits::propagate_on_container_swap::value
|| __is_nothrow_swappable<__node_allocator>::value)
);
Enable and fix warnings during the build. Although CMake adds warning flags, they are ignored in the libc++ headers because the headers '#pragma system header' themselves. This patch disables the system header pragma when building libc++ and fixes the warnings that arose. The warnings fixed were: 1. <memory> - anonymous structs are a GNU extension 2. <functional> - anonymous structs are a GNU extension. 3. <__hash_table> - Embedded preprocessor directives have undefined behavior. 4. <string> - Definition is missing noexcept from declaration. 5. <__std_stream> - Unused variable. llvm-svn: 242623
2015-07-19 04:40:46 +08:00
#else
_NOEXCEPT_(__is_nothrow_swappable<hasher>::value && __is_nothrow_swappable<key_equal>::value);
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
size_type max_bucket_count() const _NOEXCEPT
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
{return __pointer_alloc_traits::max_size(__bucket_list_.get_deleter().__alloc());}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type bucket_size(size_type __n) const;
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY float load_factor() const _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
size_type __bc = bucket_count();
return __bc != 0 ? (float)size() / __bc : 0.f;
}
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_LIBCPP_INLINE_VISIBILITY void max_load_factor(float __mlf) _NOEXCEPT
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
{
_LIBCPP_ASSERT(__mlf > 0,
"unordered container::max_load_factor(lf) called with lf <= 0");
max_load_factor() = _VSTD::max(__mlf, load_factor());
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
_LIBCPP_INLINE_VISIBILITY
local_iterator
begin(size_type __n)
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
_LIBCPP_ASSERT(__n < bucket_count(),
"unordered container::begin(n) called with n >= bucket_count()");
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return local_iterator(__bucket_list_[__n], __n, bucket_count(), this);
#else
return local_iterator(__bucket_list_[__n], __n, bucket_count());
#endif
}
_LIBCPP_INLINE_VISIBILITY
local_iterator
end(size_type __n)
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
_LIBCPP_ASSERT(__n < bucket_count(),
"unordered container::end(n) called with n >= bucket_count()");
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return local_iterator(nullptr, __n, bucket_count(), this);
#else
return local_iterator(nullptr, __n, bucket_count());
#endif
}
_LIBCPP_INLINE_VISIBILITY
const_local_iterator
cbegin(size_type __n) const
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
_LIBCPP_ASSERT(__n < bucket_count(),
"unordered container::cbegin(n) called with n >= bucket_count()");
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return const_local_iterator(__bucket_list_[__n], __n, bucket_count(), this);
#else
return const_local_iterator(__bucket_list_[__n], __n, bucket_count());
#endif
}
_LIBCPP_INLINE_VISIBILITY
const_local_iterator
cend(size_type __n) const
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
_LIBCPP_ASSERT(__n < bucket_count(),
"unordered container::cend(n) called with n >= bucket_count()");
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return const_local_iterator(nullptr, __n, bucket_count(), this);
#else
return const_local_iterator(nullptr, __n, bucket_count());
#endif
}
#if _LIBCPP_DEBUG_LEVEL >= 2
bool __dereferenceable(const const_iterator* __i) const;
bool __decrementable(const const_iterator* __i) const;
bool __addable(const const_iterator* __i, ptrdiff_t __n) const;
bool __subscriptable(const const_iterator* __i, ptrdiff_t __n) const;
#endif // _LIBCPP_DEBUG_LEVEL >= 2
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
private:
void __rehash(size_type __n);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
#ifndef _LIBCPP_HAS_NO_VARIADICS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class ..._Args>
__node_holder __construct_node(_Args&& ...__args);
Fix whitespace llvm-svn: 113089
2010-09-05 07:46:48 +08:00
#endif // _LIBCPP_HAS_NO_VARIADICS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_holder __construct_node(value_type&& __v, size_t __hash);
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#else // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_holder __construct_node(const value_type& __v);
#endif
__node_holder __construct_node(const value_type& __v, size_t __hash);
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
void __copy_assign_alloc(const __hash_table& __u)
{__copy_assign_alloc(__u, integral_constant<bool,
__node_traits::propagate_on_container_copy_assignment::value>());}
void __copy_assign_alloc(const __hash_table& __u, true_type);
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
Quash a whole bunch of warnings llvm-svn: 145624
2011-12-02 04:21:04 +08:00
void __copy_assign_alloc(const __hash_table&, false_type) {}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
void __move_assign(__hash_table& __u, false_type);
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
void __move_assign(__hash_table& __u, true_type)
_NOEXCEPT_(
is_nothrow_move_assignable<__node_allocator>::value &&
is_nothrow_move_assignable<hasher>::value &&
is_nothrow_move_assignable<key_equal>::value);
_LIBCPP_INLINE_VISIBILITY
void __move_assign_alloc(__hash_table& __u)
_NOEXCEPT_(
!__node_traits::propagate_on_container_move_assignment::value ||
(is_nothrow_move_assignable<__pointer_allocator>::value &&
is_nothrow_move_assignable<__node_allocator>::value))
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{__move_assign_alloc(__u, integral_constant<bool,
__node_traits::propagate_on_container_move_assignment::value>());}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
void __move_assign_alloc(__hash_table& __u, true_type)
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(
is_nothrow_move_assignable<__pointer_allocator>::value &&
is_nothrow_move_assignable<__node_allocator>::value)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
__bucket_list_.get_deleter().__alloc() =
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
_VSTD::move(__u.__bucket_list_.get_deleter().__alloc());
__node_alloc() = _VSTD::move(__u.__node_alloc());
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
_LIBCPP_INLINE_VISIBILITY
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
void __move_assign_alloc(__hash_table&, false_type) _NOEXCEPT {}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
void __deallocate(__node_pointer __np) _NOEXCEPT;
__node_pointer __detach() _NOEXCEPT;
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
2013-08-13 02:38:34 +08:00
template <class, class, class, class, class> friend class _LIBCPP_TYPE_VIS_ONLY unordered_map;
template <class, class, class, class, class> friend class _LIBCPP_TYPE_VIS_ONLY unordered_multimap;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
};
template <class _Tp, class _Hash, class _Equal, class _Alloc>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table()
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(
is_nothrow_default_constructible<__bucket_list>::value &&
is_nothrow_default_constructible<__first_node>::value &&
is_nothrow_default_constructible<hasher>::value &&
is_nothrow_default_constructible<key_equal>::value)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
: __p2_(0),
__p3_(1.0f)
{
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(const hasher& __hf,
const key_equal& __eql)
: __bucket_list_(nullptr, __bucket_list_deleter()),
__p1_(),
__p2_(0, __hf),
__p3_(1.0f, __eql)
{
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(const hasher& __hf,
const key_equal& __eql,
const allocator_type& __a)
: __bucket_list_(nullptr, __bucket_list_deleter(__pointer_allocator(__a), 0)),
__p1_(__node_allocator(__a)),
__p2_(0, __hf),
__p3_(1.0f, __eql)
{
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(const allocator_type& __a)
: __bucket_list_(nullptr, __bucket_list_deleter(__pointer_allocator(__a), 0)),
__p1_(__node_allocator(__a)),
__p2_(0),
__p3_(1.0f)
{
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(const __hash_table& __u)
: __bucket_list_(nullptr,
__bucket_list_deleter(allocator_traits<__pointer_allocator>::
select_on_container_copy_construction(
__u.__bucket_list_.get_deleter().__alloc()), 0)),
__p1_(allocator_traits<__node_allocator>::
select_on_container_copy_construction(__u.__node_alloc())),
__p2_(0, __u.hash_function()),
__p3_(__u.__p3_)
{
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(const __hash_table& __u,
const allocator_type& __a)
: __bucket_list_(nullptr, __bucket_list_deleter(__pointer_allocator(__a), 0)),
__p1_(__node_allocator(__a)),
__p2_(0, __u.hash_function()),
__p3_(__u.__p3_)
{
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(__hash_table&& __u)
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(
is_nothrow_move_constructible<__bucket_list>::value &&
is_nothrow_move_constructible<__first_node>::value &&
is_nothrow_move_constructible<hasher>::value &&
is_nothrow_move_constructible<key_equal>::value)
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
: __bucket_list_(_VSTD::move(__u.__bucket_list_)),
__p1_(_VSTD::move(__u.__p1_)),
__p2_(_VSTD::move(__u.__p2_)),
__p3_(_VSTD::move(__u.__p3_))
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
if (size() > 0)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__bucket_list_[__constrain_hash(__p1_.first().__next_->__hash_, bucket_count())] =
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__u.__p1_.first().__next_ = nullptr;
__u.size() = 0;
}
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__hash_table(__hash_table&& __u,
const allocator_type& __a)
: __bucket_list_(nullptr, __bucket_list_deleter(__pointer_allocator(__a), 0)),
__p1_(__node_allocator(__a)),
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__p2_(0, _VSTD::move(__u.hash_function())),
__p3_(_VSTD::move(__u.__p3_))
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
if (__a == allocator_type(__u.__node_alloc()))
{
__bucket_list_.reset(__u.__bucket_list_.release());
__bucket_list_.get_deleter().size() = __u.__bucket_list_.get_deleter().size();
__u.__bucket_list_.get_deleter().size() = 0;
if (__u.size() > 0)
{
__p1_.first().__next_ = __u.__p1_.first().__next_;
__u.__p1_.first().__next_ = nullptr;
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__bucket_list_[__constrain_hash(__p1_.first().__next_->__hash_, bucket_count())] =
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size() = __u.size();
__u.size() = 0;
}
}
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::~__hash_table()
{
__deallocate(__p1_.first().__next_);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__erase_c(this);
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__copy_assign_alloc(
const __hash_table& __u, true_type)
{
if (__node_alloc() != __u.__node_alloc())
{
clear();
__bucket_list_.reset();
__bucket_list_.get_deleter().size() = 0;
}
__bucket_list_.get_deleter().__alloc() = __u.__bucket_list_.get_deleter().__alloc();
__node_alloc() = __u.__node_alloc();
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
__hash_table<_Tp, _Hash, _Equal, _Alloc>&
__hash_table<_Tp, _Hash, _Equal, _Alloc>::operator=(const __hash_table& __u)
{
if (this != &__u)
{
__copy_assign_alloc(__u);
hash_function() = __u.hash_function();
key_eq() = __u.key_eq();
max_load_factor() = __u.max_load_factor();
__assign_multi(__u.begin(), __u.end());
}
return *this;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__deallocate(__node_pointer __np)
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
__node_allocator& __na = __node_alloc();
while (__np != nullptr)
{
__node_pointer __next = __np->__next_;
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
__c_node* __c = __get_db()->__find_c_and_lock(this);
for (__i_node** __p = __c->end_; __p != __c->beg_; )
{
--__p;
iterator* __i = static_cast<iterator*>((*__p)->__i_);
if (__i->__node_ == __np)
{
(*__p)->__c_ = nullptr;
if (--__c->end_ != __p)
memmove(__p, __p+1, (__c->end_ - __p)*sizeof(__i_node*));
}
}
__get_db()->unlock();
#endif
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_traits::destroy(__na, _VSTD::addressof(__np->__value_));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_traits::deallocate(__na, __np, 1);
__np = __next;
}
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_pointer
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__detach() _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
size_type __bc = bucket_count();
for (size_type __i = 0; __i < __bc; ++__i)
__bucket_list_[__i] = nullptr;
size() = 0;
__node_pointer __cache = __p1_.first().__next_;
__p1_.first().__next_ = nullptr;
return __cache;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__move_assign(
__hash_table& __u, true_type)
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(
is_nothrow_move_assignable<__node_allocator>::value &&
is_nothrow_move_assignable<hasher>::value &&
is_nothrow_move_assignable<key_equal>::value)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
clear();
__bucket_list_.reset(__u.__bucket_list_.release());
__bucket_list_.get_deleter().size() = __u.__bucket_list_.get_deleter().size();
__u.__bucket_list_.get_deleter().size() = 0;
__move_assign_alloc(__u);
size() = __u.size();
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
hash_function() = _VSTD::move(__u.hash_function());
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
max_load_factor() = __u.max_load_factor();
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
key_eq() = _VSTD::move(__u.key_eq());
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__p1_.first().__next_ = __u.__p1_.first().__next_;
if (size() > 0)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__bucket_list_[__constrain_hash(__p1_.first().__next_->__hash_, bucket_count())] =
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__u.__p1_.first().__next_ = nullptr;
__u.size() = 0;
}
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->swap(this, &__u);
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__move_assign(
__hash_table& __u, false_type)
{
if (__node_alloc() == __u.__node_alloc())
__move_assign(__u, true_type());
else
{
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
hash_function() = _VSTD::move(__u.hash_function());
key_eq() = _VSTD::move(__u.key_eq());
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
max_load_factor() = __u.max_load_factor();
if (bucket_count() != 0)
{
__node_pointer __cache = __detach();
#ifndef _LIBCPP_NO_EXCEPTIONS
try
{
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
#endif // _LIBCPP_NO_EXCEPTIONS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
const_iterator __i = __u.begin();
while (__cache != nullptr && __u.size() != 0)
{
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__cache->__value_ = _VSTD::move(__u.remove(__i++)->__value_);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_pointer __next = __cache->__next_;
__node_insert_multi(__cache);
__cache = __next;
}
#ifndef _LIBCPP_NO_EXCEPTIONS
}
catch (...)
{
__deallocate(__cache);
throw;
}
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
#endif // _LIBCPP_NO_EXCEPTIONS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__deallocate(__cache);
}
const_iterator __i = __u.begin();
while (__u.size() != 0)
{
__node_holder __h =
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__construct_node(_VSTD::move(__u.remove(__i++)->__value_));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_insert_multi(__h.get());
__h.release();
}
}
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>&
__hash_table<_Tp, _Hash, _Equal, _Alloc>::operator=(__hash_table&& __u)
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(
__node_traits::propagate_on_container_move_assignment::value &&
is_nothrow_move_assignable<__node_allocator>::value &&
is_nothrow_move_assignable<hasher>::value &&
is_nothrow_move_assignable<key_equal>::value)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
__move_assign(__u, integral_constant<bool,
__node_traits::propagate_on_container_move_assignment::value>());
return *this;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _InputIterator>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__assign_unique(_InputIterator __first,
_InputIterator __last)
{
if (bucket_count() != 0)
{
__node_pointer __cache = __detach();
#ifndef _LIBCPP_NO_EXCEPTIONS
try
{
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
#endif // _LIBCPP_NO_EXCEPTIONS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
for (; __cache != nullptr && __first != __last; ++__first)
{
__cache->__value_ = *__first;
__node_pointer __next = __cache->__next_;
__node_insert_unique(__cache);
__cache = __next;
}
#ifndef _LIBCPP_NO_EXCEPTIONS
}
catch (...)
{
__deallocate(__cache);
throw;
}
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
#endif // _LIBCPP_NO_EXCEPTIONS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__deallocate(__cache);
}
for (; __first != __last; ++__first)
__insert_unique(*__first);
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _InputIterator>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__assign_multi(_InputIterator __first,
_InputIterator __last)
{
if (bucket_count() != 0)
{
__node_pointer __cache = __detach();
#ifndef _LIBCPP_NO_EXCEPTIONS
try
{
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
#endif // _LIBCPP_NO_EXCEPTIONS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
for (; __cache != nullptr && __first != __last; ++__first)
{
__cache->__value_ = *__first;
__node_pointer __next = __cache->__next_;
__node_insert_multi(__cache);
__cache = __next;
}
#ifndef _LIBCPP_NO_EXCEPTIONS
}
catch (...)
{
__deallocate(__cache);
throw;
}
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
#endif // _LIBCPP_NO_EXCEPTIONS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__deallocate(__cache);
}
for (; __first != __last; ++__first)
__insert_multi(*__first);
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::begin() _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return iterator(__p1_.first().__next_, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return iterator(__p1_.first().__next_);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::end() _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return iterator(nullptr, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return iterator(nullptr);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::begin() const _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return const_iterator(__p1_.first().__next_, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return const_iterator(__p1_.first().__next_);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::end() const _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return const_iterator(nullptr, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return const_iterator(nullptr);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::clear() _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
if (size() > 0)
{
__deallocate(__p1_.first().__next_);
__p1_.first().__next_ = nullptr;
size_type __bc = bucket_count();
Fix uninitialized loop counter. http://llvm.org/bugs/show_bug.cgi?id=10278 llvm-svn: 134405
2011-07-05 22:14:17 +08:00
for (size_type __i = 0; __i < __bc; ++__i)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__bucket_list_[__i] = nullptr;
size() = 0;
}
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator, bool>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_insert_unique(__node_pointer __nd)
{
__nd->__hash_ = hash_function()(__nd->__value_);
size_type __bc = bucket_count();
bool __inserted = false;
__node_pointer __ndptr;
size_t __chash;
if (__bc != 0)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__chash = __constrain_hash(__nd->__hash_, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__ndptr = __bucket_list_[__chash];
if (__ndptr != nullptr)
{
for (__ndptr = __ndptr->__next_; __ndptr != nullptr &&
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__constrain_hash(__ndptr->__hash_, __bc) == __chash;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__ndptr = __ndptr->__next_)
{
if (key_eq()(__ndptr->__value_, __nd->__value_))
goto __done;
}
}
}
{
if (size()+1 > __bc * max_load_factor() || __bc == 0)
{
Rename pow2 functions in __hash_table to reflect that they are hash specific llvm-svn: 227866
2015-02-03 05:31:48 +08:00
rehash(_VSTD::max<size_type>(2 * __bc + !__is_hash_power2(__bc),
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type(ceil(float(size() + 1) / max_load_factor()))));
__bc = bucket_count();
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__chash = __constrain_hash(__nd->__hash_, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
// insert_after __bucket_list_[__chash], or __first_node if bucket is null
__node_pointer __pn = __bucket_list_[__chash];
if (__pn == nullptr)
{
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__pn = static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__nd->__next_ = __pn->__next_;
__pn->__next_ = __nd;
// fix up __bucket_list_
__bucket_list_[__chash] = __pn;
if (__nd->__next_ != nullptr)
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__bucket_list_[__constrain_hash(__nd->__next_->__hash_, __bc)] = __nd;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
else
{
__nd->__next_ = __pn->__next_;
__pn->__next_ = __nd;
}
__ndptr = __nd;
// increment size
++size();
__inserted = true;
}
__done:
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return pair<iterator, bool>(iterator(__ndptr, this), __inserted);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return pair<iterator, bool>(iterator(__ndptr), __inserted);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_insert_multi(__node_pointer __cp)
{
__cp->__hash_ = hash_function()(__cp->__value_);
size_type __bc = bucket_count();
if (size()+1 > __bc * max_load_factor() || __bc == 0)
{
Rename pow2 functions in __hash_table to reflect that they are hash specific llvm-svn: 227866
2015-02-03 05:31:48 +08:00
rehash(_VSTD::max<size_type>(2 * __bc + !__is_hash_power2(__bc),
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type(ceil(float(size() + 1) / max_load_factor()))));
__bc = bucket_count();
}
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_t __chash = __constrain_hash(__cp->__hash_, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_pointer __pn = __bucket_list_[__chash];
if (__pn == nullptr)
{
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__pn = static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__cp->__next_ = __pn->__next_;
__pn->__next_ = __cp;
// fix up __bucket_list_
__bucket_list_[__chash] = __pn;
if (__cp->__next_ != nullptr)
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__bucket_list_[__constrain_hash(__cp->__next_->__hash_, __bc)] = __cp;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
else
{
for (bool __found = false; __pn->__next_ != nullptr &&
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__constrain_hash(__pn->__next_->__hash_, __bc) == __chash;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__pn = __pn->__next_)
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
{
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
// __found key_eq() action
// false false loop
// true true loop
// false true set __found to true
// true false break
if (__found != (__pn->__next_->__hash_ == __cp->__hash_ &&
key_eq()(__pn->__next_->__value_, __cp->__value_)))
{
if (!__found)
__found = true;
else
break;
}
}
__cp->__next_ = __pn->__next_;
__pn->__next_ = __cp;
if (__cp->__next_ != nullptr)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_t __nhash = __constrain_hash(__cp->__next_->__hash_, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
if (__nhash != __chash)
__bucket_list_[__nhash] = __cp;
}
}
++size();
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return iterator(__cp, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return iterator(__cp);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_insert_multi(
const_iterator __p, __node_pointer __cp)
{
debug mode for unordered_map. Also picked up a missing check and test in unordered_multimap. This wraps up debug mode for the unordered containers. llvm-svn: 187659
2013-08-03 01:50:49 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__p) == this,
"unordered container::emplace_hint(const_iterator, args...) called with an iterator not"
" referring to this unordered container");
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
if (__p != end() && key_eq()(*__p, __cp->__value_))
{
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__node_pointer __np = __p.__node_;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__cp->__hash_ = __np->__hash_;
size_type __bc = bucket_count();
if (size()+1 > __bc * max_load_factor() || __bc == 0)
{
Rename pow2 functions in __hash_table to reflect that they are hash specific llvm-svn: 227866
2015-02-03 05:31:48 +08:00
rehash(_VSTD::max<size_type>(2 * __bc + !__is_hash_power2(__bc),
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type(ceil(float(size() + 1) / max_load_factor()))));
__bc = bucket_count();
}
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_t __chash = __constrain_hash(__cp->__hash_, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_pointer __pp = __bucket_list_[__chash];
while (__pp->__next_ != __np)
__pp = __pp->__next_;
__cp->__next_ = __np;
__pp->__next_ = __cp;
++size();
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return iterator(__cp, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return iterator(__cp);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
return __node_insert_multi(__cp);
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator, bool>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_unique(const value_type& __x)
{
Fix PR12999 - unordered_set::insert calls operator new when no insert occurs Summary: when `unordered_set::insert(value_type&&)` was called it would be treated like `unordered_set::emplace(Args&&)` and it would allocate and construct a node before trying to insert it. This caused unnecessary allocations when the value was already in the set. This patch adds an overload to `__hash_table::__insert_unique` that specifically handles `value_type&&` more link `value_type const &`. This patch also adds a single unified insert function for values into `__hash_table` called `__insert_unique_value` that handles the cases for `__insert_unique(value_type&&)` and `__insert_unique(value_type const &)`. This patch fixes PR12999: http://llvm.org/bugs/show_bug.cgi?id=12999. Reviewers: mclow.lists, titus, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7570 llvm-svn: 239666
2015-06-13 15:18:32 +08:00
return __insert_unique_value(__x);
}
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _ValueTp>
_LIBCPP_INLINE_VISIBILITY
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator, bool>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_unique_value(_ValueTp&& __x)
#else
template <class _Tp, class _Hash, class _Equal, class _Alloc>
_LIBCPP_INLINE_VISIBILITY
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator, bool>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_unique_value(const value_type& __x)
#endif
{
#if defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES)
typedef const value_type& _ValueTp;
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_t __hash = hash_function()(__x);
size_type __bc = bucket_count();
bool __inserted = false;
__node_pointer __nd;
size_t __chash;
if (__bc != 0)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__chash = __constrain_hash(__hash, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__nd = __bucket_list_[__chash];
if (__nd != nullptr)
{
for (__nd = __nd->__next_; __nd != nullptr &&
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__constrain_hash(__nd->__hash_, __bc) == __chash;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__nd = __nd->__next_)
{
if (key_eq()(__nd->__value_, __x))
goto __done;
}
}
}
{
Fix PR12999 - unordered_set::insert calls operator new when no insert occurs Summary: when `unordered_set::insert(value_type&&)` was called it would be treated like `unordered_set::emplace(Args&&)` and it would allocate and construct a node before trying to insert it. This caused unnecessary allocations when the value was already in the set. This patch adds an overload to `__hash_table::__insert_unique` that specifically handles `value_type&&` more link `value_type const &`. This patch also adds a single unified insert function for values into `__hash_table` called `__insert_unique_value` that handles the cases for `__insert_unique(value_type&&)` and `__insert_unique(value_type const &)`. This patch fixes PR12999: http://llvm.org/bugs/show_bug.cgi?id=12999. Reviewers: mclow.lists, titus, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7570 llvm-svn: 239666
2015-06-13 15:18:32 +08:00
__node_holder __h = __construct_node(_VSTD::forward<_ValueTp>(__x), __hash);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
if (size()+1 > __bc * max_load_factor() || __bc == 0)
{
Rename pow2 functions in __hash_table to reflect that they are hash specific llvm-svn: 227866
2015-02-03 05:31:48 +08:00
rehash(_VSTD::max<size_type>(2 * __bc + !__is_hash_power2(__bc),
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type(ceil(float(size() + 1) / max_load_factor()))));
__bc = bucket_count();
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__chash = __constrain_hash(__hash, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
// insert_after __bucket_list_[__chash], or __first_node if bucket is null
__node_pointer __pn = __bucket_list_[__chash];
if (__pn == nullptr)
{
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__pn = static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__h->__next_ = __pn->__next_;
__pn->__next_ = __h.get();
// fix up __bucket_list_
__bucket_list_[__chash] = __pn;
if (__h->__next_ != nullptr)
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__bucket_list_[__constrain_hash(__h->__next_->__hash_, __bc)] = __h.get();
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
else
{
__h->__next_ = __pn->__next_;
__pn->__next_ = __h.get();
}
__nd = __h.release();
// increment size
++size();
__inserted = true;
}
__done:
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return pair<iterator, bool>(iterator(__nd, this), __inserted);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return pair<iterator, bool>(iterator(__nd), __inserted);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
#ifndef _LIBCPP_HAS_NO_VARIADICS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class... _Args>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator, bool>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__emplace_unique(_Args&&... __args)
{
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_holder __h = __construct_node(_VSTD::forward<_Args>(__args)...);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
pair<iterator, bool> __r = __node_insert_unique(__h.get());
if (__r.second)
__h.release();
return __r;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class... _Args>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__emplace_multi(_Args&&... __args)
{
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_holder __h = __construct_node(_VSTD::forward<_Args>(__args)...);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
iterator __r = __node_insert_multi(__h.get());
__h.release();
return __r;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class... _Args>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__emplace_hint_multi(
const_iterator __p, _Args&&... __args)
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__p) == this,
"unordered container::emplace_hint(const_iterator, args...) called with an iterator not"
" referring to this unordered container");
#endif
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_holder __h = __construct_node(_VSTD::forward<_Args>(__args)...);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
iterator __r = __node_insert_multi(__p, __h.get());
__h.release();
return __r;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_VARIADICS
Fix PR12999 - unordered_set::insert calls operator new when no insert occurs Summary: when `unordered_set::insert(value_type&&)` was called it would be treated like `unordered_set::emplace(Args&&)` and it would allocate and construct a node before trying to insert it. This caused unnecessary allocations when the value was already in the set. This patch adds an overload to `__hash_table::__insert_unique` that specifically handles `value_type&&` more link `value_type const &`. This patch also adds a single unified insert function for values into `__hash_table` called `__insert_unique_value` that handles the cases for `__insert_unique(value_type&&)` and `__insert_unique(value_type const &)`. This patch fixes PR12999: http://llvm.org/bugs/show_bug.cgi?id=12999. Reviewers: mclow.lists, titus, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7570 llvm-svn: 239666
2015-06-13 15:18:32 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator, bool>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_unique(value_type&& __x)
{
return __insert_unique_value(_VSTD::move(__x));
}
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
template <class _Pp>
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator, bool>
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_unique(_Pp&& __x)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__node_holder __h = __construct_node(_VSTD::forward<_Pp>(__x));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
pair<iterator, bool> __r = __node_insert_unique(__h.get());
if (__r.second)
__h.release();
return __r;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
template <class _Pp>
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_multi(_Pp&& __x)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__node_holder __h = __construct_node(_VSTD::forward<_Pp>(__x));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
iterator __r = __node_insert_multi(__h.get());
__h.release();
return __r;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
template <class _Pp>
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_multi(const_iterator __p,
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
_Pp&& __x)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__p) == this,
"unordered container::insert(const_iterator, rvalue) called with an iterator not"
" referring to this unordered container");
#endif
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__node_holder __h = __construct_node(_VSTD::forward<_Pp>(__x));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
iterator __r = __node_insert_multi(__p, __h.get());
__h.release();
return __r;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#else // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_multi(const value_type& __x)
{
__node_holder __h = __construct_node(__x);
iterator __r = __node_insert_multi(__h.get());
__h.release();
return __r;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__insert_multi(const_iterator __p,
const value_type& __x)
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__p) == this,
"unordered container::insert(const_iterator, lvalue) called with an iterator not"
" referring to this unordered container");
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_holder __h = __construct_node(__x);
iterator __r = __node_insert_multi(__p, __h.get());
__h.release();
return __r;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::rehash(size_type __n)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
if (__n == 1)
__n = 2;
else if (__n & (__n - 1))
__n = __next_prime(__n);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type __bc = bucket_count();
if (__n > __bc)
__rehash(__n);
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
else if (__n < __bc)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__n = _VSTD::max<size_type>
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
(
__n,
Rename pow2 functions in __hash_table to reflect that they are hash specific llvm-svn: 227866
2015-02-03 05:31:48 +08:00
__is_hash_power2(__bc) ? __next_hash_pow2(size_t(ceil(float(size()) / max_load_factor()))) :
__next_prime(size_t(ceil(float(size()) / max_load_factor())))
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
);
if (__n < __bc)
__rehash(__n);
}
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__rehash(size_type __nbc)
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->__invalidate_all(this);
#endif // _LIBCPP_DEBUG_LEVEL >= 2
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__pointer_allocator& __npa = __bucket_list_.get_deleter().__alloc();
__bucket_list_.reset(__nbc > 0 ?
__pointer_alloc_traits::allocate(__npa, __nbc) : nullptr);
__bucket_list_.get_deleter().size() = __nbc;
if (__nbc > 0)
{
for (size_type __i = 0; __i < __nbc; ++__i)
__bucket_list_[__i] = nullptr;
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__node_pointer __pp(static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first())));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_pointer __cp = __pp->__next_;
if (__cp != nullptr)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_type __chash = __constrain_hash(__cp->__hash_, __nbc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__bucket_list_[__chash] = __pp;
size_type __phash = __chash;
for (__pp = __cp, __cp = __cp->__next_; __cp != nullptr;
__cp = __pp->__next_)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__chash = __constrain_hash(__cp->__hash_, __nbc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
if (__chash == __phash)
__pp = __cp;
else
{
if (__bucket_list_[__chash] == nullptr)
{
__bucket_list_[__chash] = __pp;
__pp = __cp;
__phash = __chash;
}
else
{
__node_pointer __np = __cp;
for (; __np->__next_ != nullptr &&
key_eq()(__cp->__value_, __np->__next_->__value_);
__np = __np->__next_)
;
__pp->__next_ = __np->__next_;
__np->__next_ = __bucket_list_[__chash]->__next_;
__bucket_list_[__chash]->__next_ = __cp;
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
}
}
}
}
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::find(const _Key& __k)
{
size_t __hash = hash_function()(__k);
size_type __bc = bucket_count();
if (__bc != 0)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_t __chash = __constrain_hash(__hash, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_pointer __nd = __bucket_list_[__chash];
if (__nd != nullptr)
{
for (__nd = __nd->__next_; __nd != nullptr &&
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__constrain_hash(__nd->__hash_, __bc) == __chash;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__nd = __nd->__next_)
{
if (key_eq()(__nd->__value_, __k))
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return iterator(__nd, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return iterator(__nd);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
}
}
return end();
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::find(const _Key& __k) const
{
size_t __hash = hash_function()(__k);
size_type __bc = bucket_count();
if (__bc != 0)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_t __chash = __constrain_hash(__hash, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_const_pointer __nd = __bucket_list_[__chash];
if (__nd != nullptr)
{
for (__nd = __nd->__next_; __nd != nullptr &&
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__constrain_hash(__nd->__hash_, __bc) == __chash;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__nd = __nd->__next_)
{
if (key_eq()(__nd->__value_, __k))
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return const_iterator(__nd, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return const_iterator(__nd);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
}
Fixing whitespace problems llvm-svn: 111750
2010-08-22 08:02:43 +08:00
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
return end();
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
#ifndef _LIBCPP_HAS_NO_VARIADICS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class ..._Args>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_holder
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__construct_node(_Args&& ...__args)
{
__node_allocator& __na = __node_alloc();
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__node_holder __h(__node_traits::allocate(__na, 1), _Dp(__na));
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_traits::construct(__na, _VSTD::addressof(__h->__value_), _VSTD::forward<_Args>(__args)...);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__h.get_deleter().__value_constructed = true;
__h->__hash_ = hash_function()(__h->__value_);
__h->__next_ = nullptr;
return __h;
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_VARIADICS
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_holder
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__construct_node(value_type&& __v,
size_t __hash)
{
__node_allocator& __na = __node_alloc();
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__node_holder __h(__node_traits::allocate(__na, 1), _Dp(__na));
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_traits::construct(__na, _VSTD::addressof(__h->__value_), _VSTD::move(__v));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__h.get_deleter().__value_constructed = true;
__h->__hash_ = __hash;
__h->__next_ = nullptr;
Zhihao Yuan noted that there were a few unneeded statements. Eliminated the unnecessary ones, and commented the ones that are there for non-obvious reasons such as to help things limp along in C++03 language mode. llvm-svn: 189039
2013-08-23 02:29:50 +08:00
return __h;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#else // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_holder
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__construct_node(const value_type& __v)
{
__node_allocator& __na = __node_alloc();
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__node_holder __h(__node_traits::allocate(__na, 1), _Dp(__na));
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_traits::construct(__na, _VSTD::addressof(__h->__value_), __v);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__h.get_deleter().__value_constructed = true;
__h->__hash_ = hash_function()(__h->__value_);
__h->__next_ = nullptr;
Fix warnings about pessimizing return moves for C++11 and higher Summary: Throughout the libc++ headers, there are a few instances where _VSTD::move() is used to return a local variable. Howard commented in r189039 that these were there "for non-obvious reasons such as to help things limp along in C++03 language mode". However, when compiling these headers with warnings on, and in C++11 or higher mode (like we do in FreeBSD), they cause the following complaints about pessimizing moves: In file included from tests.cpp:26: In file included from tests.hpp:29: /usr/include/c++/v1/map:1368:12: error: moving a local object in a return statement prevents copy elision [-Werror,-Wpessimizing-move] return _VSTD::move(__h); // explicitly moved for C++03 ^ /usr/include/c++/v1/__config:368:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ Attempt to fix this by adding a _LIBCPP_EXPLICIT_MOVE() macro to __config, which gets defined to _VSTD::move for pre-C++11, and to nothing for C++11 and later. I am not completely satisfied with the macro name (I also considered _LIBCPP_COMPAT_MOVE and some other variants), so suggestions are welcome. :) Reviewers: mclow.lists, howard.hinnant, EricWF Subscribers: arthur.j.odwyer, cfe-commits Differential Revision: http://reviews.llvm.org/D11394 llvm-svn: 245421
2015-08-19 14:43:33 +08:00
return _LIBCPP_EXPLICIT_MOVE(__h); // explicitly moved for C++03
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
Changed __config to react to all of clang's currently documented has_feature flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
2010-09-05 07:28:19 +08:00
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_holder
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__construct_node(const value_type& __v,
size_t __hash)
{
__node_allocator& __na = __node_alloc();
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
__node_holder __h(__node_traits::allocate(__na, 1), _Dp(__na));
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
__node_traits::construct(__na, _VSTD::addressof(__h->__value_), __v);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__h.get_deleter().__value_constructed = true;
__h->__hash_ = __hash;
__h->__next_ = nullptr;
Fix warnings about pessimizing return moves for C++11 and higher Summary: Throughout the libc++ headers, there are a few instances where _VSTD::move() is used to return a local variable. Howard commented in r189039 that these were there "for non-obvious reasons such as to help things limp along in C++03 language mode". However, when compiling these headers with warnings on, and in C++11 or higher mode (like we do in FreeBSD), they cause the following complaints about pessimizing moves: In file included from tests.cpp:26: In file included from tests.hpp:29: /usr/include/c++/v1/map:1368:12: error: moving a local object in a return statement prevents copy elision [-Werror,-Wpessimizing-move] return _VSTD::move(__h); // explicitly moved for C++03 ^ /usr/include/c++/v1/__config:368:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ Attempt to fix this by adding a _LIBCPP_EXPLICIT_MOVE() macro to __config, which gets defined to _VSTD::move for pre-C++11, and to nothing for C++11 and later. I am not completely satisfied with the macro name (I also considered _LIBCPP_COMPAT_MOVE and some other variants), so suggestions are welcome. :) Reviewers: mclow.lists, howard.hinnant, EricWF Subscribers: arthur.j.odwyer, cfe-commits Differential Revision: http://reviews.llvm.org/D11394 llvm-svn: 245421
2015-08-19 14:43:33 +08:00
return _LIBCPP_EXPLICIT_MOVE(__h); // explicitly moved for C++03
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::erase(const_iterator __p)
{
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__node_pointer __np = __p.__node_;
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__p) == this,
"unordered container erase(iterator) called with an iterator not"
" referring to this container");
_LIBCPP_ASSERT(__p != end(),
"unordered container erase(iterator) called with a non-dereferenceable iterator");
iterator __r(__np, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
iterator __r(__np);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
++__r;
remove(__p);
return __r;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::erase(const_iterator __first,
const_iterator __last)
{
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__first) == this,
"unodered container::erase(iterator, iterator) called with an iterator not"
" referring to this unodered container");
_LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__last) == this,
"unodered container::erase(iterator, iterator) called with an iterator not"
" referring to this unodered container");
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
for (const_iterator __p = __first; __first != __last; __p = __first)
{
++__first;
erase(__p);
}
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__node_pointer __np = __last.__node_;
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
return iterator (__np, this);
#else
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
return iterator (__np);
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::size_type
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__erase_unique(const _Key& __k)
{
iterator __i = find(__k);
if (__i == end())
return 0;
erase(__i);
return 1;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::size_type
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__erase_multi(const _Key& __k)
{
size_type __r = 0;
iterator __i = find(__k);
if (__i != end())
{
iterator __e = end();
do
{
erase(__i++);
++__r;
} while (__i != __e && key_eq()(*__i, __k));
}
return __r;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_holder
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
__hash_table<_Tp, _Hash, _Equal, _Alloc>::remove(const_iterator __p) _NOEXCEPT
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
// current node
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
__node_pointer __cn = __p.__node_;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
size_type __bc = bucket_count();
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_t __chash = __constrain_hash(__cn->__hash_, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
// find previous node
__node_pointer __pn = __bucket_list_[__chash];
for (; __pn->__next_ != __cn; __pn = __pn->__next_)
;
// Fix up __bucket_list_
// if __pn is not in same bucket (before begin is not in same bucket) &&
// if __cn->__next_ is not in same bucket (nullptr is not in same bucket)
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
if (__pn == static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()))
|| __constrain_hash(__pn->__hash_, __bc) != __chash)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
if (__cn->__next_ == nullptr || __constrain_hash(__cn->__next_->__hash_, __bc) != __chash)
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__bucket_list_[__chash] = nullptr;
}
// if __cn->__next_ is not in same bucket (nullptr is in same bucket)
if (__cn->__next_ != nullptr)
{
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
size_t __nhash = __constrain_hash(__cn->__next_->__hash_, __bc);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
if (__nhash != __chash)
__bucket_list_[__nhash] = __pn;
}
// remove __cn
__pn->__next_ = __cn->__next_;
__cn->__next_ = nullptr;
--size();
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
__c_node* __c = __get_db()->__find_c_and_lock(this);
for (__i_node** __p = __c->end_; __p != __c->beg_; )
{
--__p;
iterator* __i = static_cast<iterator*>((*__p)->__i_);
if (__i->__node_ == __cn)
{
(*__p)->__c_ = nullptr;
if (--__c->end_ != __p)
memmove(__p, __p+1, (__c->end_ - __p)*sizeof(__i_node*));
}
}
__get_db()->unlock();
#endif
Further macro protection by replacing _[A-Z] with _[A-Z]p llvm-svn: 145410
2011-11-30 02:15:50 +08:00
return __node_holder(__cn, _Dp(__node_alloc(), true));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
visibility-decoration. llvm-svn: 114451
2010-09-22 01:32:39 +08:00
inline _LIBCPP_INLINE_VISIBILITY
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::size_type
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__count_unique(const _Key& __k) const
{
return static_cast<size_type>(find(__k) != end());
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::size_type
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__count_multi(const _Key& __k) const
{
size_type __r = 0;
const_iterator __i = find(__k);
if (__i != end())
{
const_iterator __e = end();
do
{
++__i;
++__r;
} while (__i != __e && key_eq()(*__i, __k));
}
return __r;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator,
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__equal_range_unique(
const _Key& __k)
{
iterator __i = find(__k);
iterator __j = __i;
if (__i != end())
++__j;
return pair<iterator, iterator>(__i, __j);
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator,
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__equal_range_unique(
const _Key& __k) const
{
const_iterator __i = find(__k);
const_iterator __j = __i;
if (__i != end())
++__j;
return pair<const_iterator, const_iterator>(__i, __j);
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator,
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__equal_range_multi(
const _Key& __k)
{
iterator __i = find(__k);
iterator __j = __i;
if (__i != end())
{
iterator __e = end();
do
{
++__j;
} while (__j != __e && key_eq()(*__j, __k));
}
return pair<iterator, iterator>(__i, __j);
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
pair<typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator,
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator>
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__equal_range_multi(
const _Key& __k) const
{
const_iterator __i = find(__k);
const_iterator __j = __i;
if (__i != end())
{
const_iterator __e = end();
do
{
++__j;
} while (__j != __e && key_eq()(*__j, __k));
}
return pair<const_iterator, const_iterator>(__i, __j);
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::swap(__hash_table& __u)
Enable and fix warnings during the build. Although CMake adds warning flags, they are ignored in the libc++ headers because the headers '#pragma system header' themselves. This patch disables the system header pragma when building libc++ and fixes the warnings that arose. The warnings fixed were: 1. <memory> - anonymous structs are a GNU extension 2. <functional> - anonymous structs are a GNU extension. 3. <__hash_table> - Embedded preprocessor directives have undefined behavior. 4. <string> - Definition is missing noexcept from declaration. 5. <__std_stream> - Unused variable. llvm-svn: 242623
2015-07-19 04:40:46 +08:00
#if _LIBCPP_STD_VER <= 11
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
_NOEXCEPT_(
Implement the first part of N4258: 'Cleaning up noexcept in the Library'. This patch deals with swapping containers, and implements a more strict noexcept specification (a conforming extension) than the standard mandates. llvm-svn: 242056
2015-07-14 04:04:56 +08:00
__is_nothrow_swappable<hasher>::value && __is_nothrow_swappable<key_equal>::value
&& (!allocator_traits<__pointer_allocator>::propagate_on_container_swap::value
|| __is_nothrow_swappable<__pointer_allocator>::value)
&& (!__node_traits::propagate_on_container_swap::value
|| __is_nothrow_swappable<__node_allocator>::value)
)
Enable and fix warnings during the build. Although CMake adds warning flags, they are ignored in the libc++ headers because the headers '#pragma system header' themselves. This patch disables the system header pragma when building libc++ and fixes the warnings that arose. The warnings fixed were: 1. <memory> - anonymous structs are a GNU extension 2. <functional> - anonymous structs are a GNU extension. 3. <__hash_table> - Embedded preprocessor directives have undefined behavior. 4. <string> - Definition is missing noexcept from declaration. 5. <__std_stream> - Unused variable. llvm-svn: 242623
2015-07-19 04:40:46 +08:00
#else
_NOEXCEPT_(__is_nothrow_swappable<hasher>::value && __is_nothrow_swappable<key_equal>::value)
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
{
{
__node_pointer_pointer __npp = __bucket_list_.release();
__bucket_list_.reset(__u.__bucket_list_.release());
__u.__bucket_list_.reset(__npp);
}
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
_VSTD::swap(__bucket_list_.get_deleter().size(), __u.__bucket_list_.get_deleter().size());
Implement the first part of N4258: 'Cleaning up noexcept in the Library'. This patch deals with swapping containers, and implements a more strict noexcept specification (a conforming extension) than the standard mandates. llvm-svn: 242056
2015-07-14 04:04:56 +08:00
__swap_allocator(__bucket_list_.get_deleter().__alloc(),
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__u.__bucket_list_.get_deleter().__alloc());
Implement the first part of N4258: 'Cleaning up noexcept in the Library'. This patch deals with swapping containers, and implements a more strict noexcept specification (a conforming extension) than the standard mandates. llvm-svn: 242056
2015-07-14 04:04:56 +08:00
__swap_allocator(__node_alloc(), __u.__node_alloc());
_STD -> _VSTD to avoid macro clash on windows llvm-svn: 134190
2011-07-01 05:18:19 +08:00
_VSTD::swap(__p1_.first().__next_, __u.__p1_.first().__next_);
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__p2_.swap(__u.__p2_);
__p3_.swap(__u.__p3_);
if (size() > 0)
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__bucket_list_[__constrain_hash(__p1_.first().__next_->__hash_, bucket_count())] =
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__p1_.first()));
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
if (__u.size() > 0)
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__u.__bucket_list_[__constrain_hash(__u.__p1_.first().__next_->__hash_, __u.bucket_count())] =
Implement full support for non-pointer types in custom allocators. This is for the unordered containers only. This work still needs to be done on the sequence containers. llvm-svn: 184635
2013-06-22 23:21:29 +08:00
static_cast<__node_pointer>(pointer_traits<__node_base_pointer>::pointer_to(__u.__p1_.first()));
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
__get_db()->swap(this, &__u);
#endif
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::size_type
__hash_table<_Tp, _Hash, _Equal, _Alloc>::bucket_size(size_type __n) const
{
Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well. There are actually two debug modes: 1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1 This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations. 2. -D_LIBCPP_DEBUG2=0 This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity. llvm-svn: 187369
2013-07-30 03:05:47 +08:00
_LIBCPP_ASSERT(__n < bucket_count(),
"unordered container::bucket_size(n) called with n >= bucket_count()");
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__node_const_pointer __np = __bucket_list_[__n];
size_type __bc = bucket_count();
size_type __r = 0;
if (__np != nullptr)
{
for (__np = __np->__next_; __np != nullptr &&
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have. llvm-svn: 159836
2012-07-07 01:31:14 +08:00
__constrain_hash(__np->__hash_, __bc) == __n;
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
__np = __np->__next_, ++__r)
;
}
return __r;
}
noexcept for <unordered_map>. llvm-svn: 132646
2011-06-05 02:54:24 +08:00
template <class _Tp, class _Hash, class _Equal, class _Alloc>
inline _LIBCPP_INLINE_VISIBILITY
void
swap(__hash_table<_Tp, _Hash, _Equal, _Alloc>& __x,
__hash_table<_Tp, _Hash, _Equal, _Alloc>& __y)
_NOEXCEPT_(_NOEXCEPT_(__x.swap(__y)))
{
__x.swap(__y);
}
Debug mode for unordered_set. I believe this to be fairly complete for unordered_set, however it is not complete yet for unordered_multiset, unordered_map or unordered_multimap. There has been a lot of work done for these other three containers, however that work was done just to keep all of the tests passing. You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a libc++.dylib that has been compiled with src/debug.cpp. So far, vector (but not vector<bool>), list, and unordered_set are treated. I hope to get the other three unordered containers up fairly quickly now that unordered_set is done. The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but not today. This is my second effort at getting debug mode going for libc++, and I'm not quite yet ready to throw all of the work under the first attempt away. The basic design is that all of the debug information is kept in a central database, instead of in the containers. This has been done as an attempt to have debug mode and non-debug mode be ABI compatible with each other. There are some circumstances where if you construct a container in an environment without debug mode and pass it into debug mode, the checking will get confused and let you know with a readable error message. Passing containers the other way: from debug mode out to a non-debugging mode container should be 100% safe (at least that is the goal). llvm-svn: 186991
2013-07-24 06:01:58 +08:00
#if _LIBCPP_DEBUG_LEVEL >= 2
template <class _Tp, class _Hash, class _Equal, class _Alloc>
bool
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__dereferenceable(const const_iterator* __i) const
{
return __i->__node_ != nullptr;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
bool
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__decrementable(const const_iterator*) const
{
return false;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
bool
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__addable(const const_iterator*, ptrdiff_t) const
{
return false;
}
template <class _Tp, class _Hash, class _Equal, class _Alloc>
bool
__hash_table<_Tp, _Hash, _Equal, _Alloc>::__subscriptable(const const_iterator*, ptrdiff_t) const
{
return false;
}
#endif // _LIBCPP_DEBUG_LEVEL >= 2
libcxx initial import llvm-svn: 103490
2010-05-12 03:42:16 +08:00
_LIBCPP_END_NAMESPACE_STD
#endif // _LIBCPP__HASH_TABLE