- Jul 20, 2012
-
-
Howard Hinnant authored
llvm-svn: 160566
-
Howard Hinnant authored
llvm-svn: 160565
-
Howard Hinnant authored
llvm-svn: 160564
-
Howard Hinnant authored
llvm-svn: 160563
-
Howard Hinnant authored
llvm-svn: 160562
-
- Jul 19, 2012
-
-
Howard Hinnant authored
llvm-svn: 160510
-
Howard Hinnant authored
llvm-svn: 160509
-
- Jul 16, 2012
-
-
Howard Hinnant authored
Relax the complete-type checks that are happening under __invokable<Fp, Args...> to only check Fp, and not Args... . This should be sufficient to give the desired high quality diagnostics under both bind and function. And this allows a test reported by Rich E on cfe-dev to pass. Tracked by <rdar://problem/11880602>. llvm-svn: 160285
-
- Jul 13, 2012
-
-
Howard Hinnant authored
llvm-svn: 160184
-
- Jul 12, 2012
-
-
Howard Hinnant authored
Fixed a bug in wstring_convert concerning zero-length inputs. Thanks to Jonathan Coxhead for reporting this bug. llvm-svn: 160136
-
- Jul 11, 2012
-
-
Richard Smith authored
llvm-svn: 160038
-
- Jul 09, 2012
-
-
Howard Hinnant authored
llvm-svn: 159921
-
Howard Hinnant authored
Change emplace for vector and deque to create the temporary (when necessary) before any changes to the container are made. Nikolay Ivchenkov deserves the credit for pushing this problem and the solution for it. llvm-svn: 159918
-
- Jul 07, 2012
-
-
Howard Hinnant authored
llvm-svn: 159902
-
Howard Hinnant authored
Apply constexpr to the mutex constructor. As a conforming extension, apply constexpr to the condition_variable constructor. These are important because it enables the compiler to construct these types at compile time, even though the object will be non-const. Since they are constructed at compile time, there is no chance of a data race before they are constructed. llvm-svn: 159901
-
Howard Hinnant authored
llvm-svn: 159899
-
- Jul 06, 2012
-
-
Howard Hinnant authored
llvm-svn: 159865
-
Howard Hinnant authored
As a conforming extension give tuple a noexcept default constructor conditionalized on its held types. llvm-svn: 159858
-
Howard Hinnant authored
llvm-svn: 159857
-
Howard Hinnant authored
llvm-svn: 159852
-
Howard Hinnant authored
llvm-svn: 159850
-
Howard Hinnant authored
llvm-svn: 159849
-
Howard Hinnant authored
llvm-svn: 159846
-
Howard Hinnant authored
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
-
Howard Hinnant authored
llvm-svn: 159791
-
- Jun 28, 2012
-
-
Nuno Lopes authored
llvm-svn: 159359
-
- Jun 26, 2012
-
-
Howard Hinnant authored
Fixed a bug regarding result_of reported by Sven Behne. The fix is C++11 only mainly because result_of is a variadic beast and working with variadics is just such a problem in C++03 mode. This should bring result_of up to full conformance with the C++11 spec. llvm-svn: 159211
-
Nuno Lopes authored
llvm-svn: 159177
-
- Jun 09, 2012
-
-
Howard Hinnant authored
Revert pair constructors back to using is_convertible instead of is_constructible. This should pull things into alignment with the final draft. Fixes http://llvm.org/bugs/show_bug.cgi?id=13063#add_comment. llvm-svn: 158280
-
- Jun 08, 2012
-
-
Douglas Gregor authored
llvm-svn: 158172
-
- Jun 01, 2012
-
-
Howard Hinnant authored
llvm-svn: 157832
-
Howard Hinnant authored
llvm-svn: 157779
-
- May 31, 2012
-
-
Howard Hinnant authored
llvm-svn: 157765
-
Howard Hinnant authored
llvm-svn: 157764
-
- May 26, 2012
-
-
Howard Hinnant authored
The rules for emplace in map, multimap, unordered_map and unordered_multimap changed a while back and I'm just now updating to these new rules. In a nutshell, you've got to know you're emplacing to a pair and use one of pair's constructors. I made one extension: If you want to emplace the key and default construct the mapped_type, you can just emplace(key), as opposed to emplace(piecewise_construct, forward_as_tuple(key), forward_as_tuple()). llvm-svn: 157503
-
- May 25, 2012
-
-
Howard Hinnant authored
llvm-svn: 157476
-
- May 20, 2012
-
-
Howard Hinnant authored
llvm-svn: 157157
-
- May 19, 2012
-
-
http://llvm.org/bugs/show_bug.cgi?id=12867Howard Hinnant authored
Revert fix to http://llvm.org/bugs/show_bug.cgi?id=12867 for the reason now included in the code comment. llvm-svn: 157128
-
Douglas Gregor authored
llvm-svn: 157108
-
Douglas Gregor authored
llvm-svn: 157107
-