Includes:
* concepts `three_way_comparable` and `three_way_comparable_with`,
* type trait `std::compare_three_way_result` (with `_t` alias), and
* function object `compare_three_way`.
in `<compare>`, and:
* function objects `ranges::equal_to` and `ranges::less` (in `<xutility>` for
easy algorithm access), `ranges::not_equal_to`, `ranges::less_equal`,
`ranges::greater`, and `ranges::greater_equal` (in `<functional>`),
* slight refactoring of concept definitions in `<concepts>` to avoid redundant
requirements for the single-type comparison concepts `equality_comparable`,
`totally_ordered`, and `three_way_comparable`,
* heavy refactoring of the trait `common_comparison_category` (and `_t` alias)
in `<compare>` to requires only `n + c` template instantiations instead of `cn`
template instantiations,
* ======== ABI BREAK =========== remove the `_Is_unordered` member from
`std::partial_ordering` in `<compare>` since (a) it's true if and only if the
stored value has a particular value, and (b) Clang expects all of the
comparison category types to have size 1,
* reorder all `is_transparent` alias declarations in the STL to be after the
corresponding `operator()` to agree with synopsis order.
Also adds a new test `P0896R4_P1614R2_comparisons` that exercises the above.
The ABI BREAK sounds scary - as it should - but note that:
* this is a `/std:c++latest` feature, which is subject to change,
* objects of comparison category type aren't typically stored,
* only MSVC has released `<compare>` so far, so it's not widely used.
Altogether, it's extremely unlikely that anyone has encoded this in ABI.
This avoids the allocation in _Winerror_message, and introduces a new version of it which uses FORMAT_MESSAGE_ALLOCATE_BUFFER to completely avoid overallocating memory
Fixes#434
Co-authored-by: Billy O'Neal <billy.oneal@gmail.com>
Co-authored-by: Casey Carter <cartec69@gmail.com>
Deletes stream insertion operators for `ostream` with non-`char` character types, and for `wostream` with `charX_t` character types. The `char8_t` operators are deleted in all language modes, but the others are C++20-only to avoid gratuitous breakage (with escape hatch `_HAS_STREAM_INSERTIONS_REMOVED_IN_CXX20`).
Skips libc++ tests that expect the pre-P1423R3 value of `__cpp_lib_char8_t`.
Resolves#59.
* <span>: fix cross-type iterator operations
* Implement `<=>` for C++20 relational operator rewrites.
* `span<T>::operator-` now accepts `_Span_iterator<U>` when `remove_cv_t<T>` and `remove_cv_t<U>` are the same type.
Drive-by: implement `n + span_iterator` as a hidden friend, and make it `constexpr`.
Fixes#473.
I built clang from the `release/10.x` branch to investigate support for the portions of the STL that require concepts. This went swimmingly, until I was blocked by LLVM-44627 "Reversed candidate operator is not found by argument dependent lookup". These are a few fixes and workarounds I discovered in the process of getting some tests to pass before being blocked completely.
Detailed changes:
`<compare>`:
* Workaround LLVM-41991 "c++2a: attributes on defaulted friend functions incorrectly rejected" by using `_NODISCARD` on such functions only for non-clang.
`<concepts>`:
* Fix typo.
* Workaround LLVM-44689 "[concepts] ICE when *this appears in trailing requires-clause" in `std::ranges::swap`.
`<xhash>`:
* Silence clang warning about template parameter shadowing by renaming.
`<xutility>`:
* Clang thinks my `unreachable_sentinel_t` hack is ill-formed.
This reverts #289 and changes several more algorithms.
Unrelated cleanup: this changes one occurrence of `[[nodiscard]]`
to `_NODISCARD` for consistency.
iso646.h: This suppression is no longer necessary. (Apparently
unrelated to LLVM-43531, fixed after Clang 9.)
xutility: This exceeded 120 columns. clang-format doesn't make it
unreadable, so we should just enable it.
In GH-425 I was forced to add a dead initialization for the _Count variable in _Sort_unchecked in order to comply with constexpr rules. Also, _Sort_unchecked had somewhat complex assignment-in-conditional-expressions going on. This change moves the code around such that the _Count variable is assigned once.
Also:
* Consistently test _ISORT_MAX with <= where possible, and make that an _INLINE_VAR constexpr variable.
* Remove _Count guards of 1 in front of _Insertion_sort_unchecked for consistency. I did performance testing and there was no measurable difference in keeping this check, and it's more code to reason about.
* Avoid needless casts of _ISORT_MAX given that it is now a constexpr constant.
* Implement fixes from D2091R0 "Issues with Range Access CPOs"
* Pre-existing: Correctly annotate implementations of outstanding `iter_move` LWG issues. LWG-3247 was not annotated, and LWG-3299 incorrectly annotated as LWG-3270 (the number had to be changed after submission).
* Remove the `initializer_list` poison pills for `ranges::begin`, `ranges::end`, `ranges::rbegin`, and `ranges::rend`. They were necessary only to prevent `initializer_list` from inadvertently opting-in to forwarding-range, and P1870R1 "forwarding-range<T> is too subtle" changed the opt-in.
* Always perform lookups for lvalues in `ranges::size`, `ranges::empty`, and `ranges::data` as is already the case for `ranges::begin`, `ranges::end`, `ranges::rbegin`, and `ranges::rend` post-P1870, which makes the CPOs easier to reason about and reduces template instantiations.
* Replace forwarding-reference poison pills with pairs of lvalue/const lvalue poison pills for `ranges::begin`, `ranges::end`, `ranges::rbegin`, `ranges::rend`, and `ranges::size`; the forwarding-reference versions are insufficiently poisonous and allow calls to plain `meow(auto&)`/`meow(const auto&)` templates.
* Only perform ADL probes in `ranges::begin`, `ranges::end`, `ranges::rbegin`, `ranges::rend`, and `ranges::size` for argument expressions of class or enumeration type.
* `ranges::begin`, `ranges::empty`, `ranges::data` accept (lvalue) arrays of unknown bound; `ranges::end` (and consequently `ranges::rbegin` and `ranges::rend`) rejects. Remove `range` constraint from `iterator_t`, so it works with (non-`range`) arrays of unknown bound. Add `range` constraints to the `range_meow_t` "compound" associated type traits, since they no longer get it from `iterator_t`.
* Hard error (with a pretty message) in `ranges::begin`, `ranges::end`, `ranges::rbegin`, or `ranges::rend` when the argument is an array whose element type is incomplete.
This bug is triggered when unqualified name lookup for `f` in `f(x)` finds only deleted function (template)s at template definition time, resulting in MSVC refusing to perform argument dependent lookup at template instantiation time. Unsurprisingly, all of the C++20 CPOs required workarounds.
* Implement constexpr algorithms.
Resolves GH-6 ( P0202R3 ), resolves GH-38 ( P0879R0 ), and drive-by fixes GH-414.
Everywhere: Add constexpr, _CONSTEXPR20, and _CONSTEXPR20_ICE to things.
skipped_tests.txt: Turn on all tests previously blocked by missing constexpr algorithms (and exchange and swap). Mark those algorithms that cannot be turned on that we have outstanding PRs for with their associated PRs.
yvals_core.h: Turn on feature test macros.
xutility:
* Move the _Ptr_cat family down to copy, and fix associated SHOUTY comments to indicate that this is really an implementation detail of copy, not something the rest of the standard library intends to use directly. Removed and clarified some of the comments as requested by Casey Carter.
* Extract _Copy_n_core which implements copy_n using only the core language (rather than memcpy-as-an-intrinsic). Note that we cannot use __builtin_memcpy or similar to avoid the is_constant_evaluated check here; builtin_memcpy only works in constexpr contexts when the inputs are of type char.
numeric: Refactor as suggested by GH-414.
* Attempt alternate fix of GH-414 suggested by Stephan.
* Stephan product code PR comments:
* _Swap_ranges_unchecked => _CONSTEXPR20
* _Idl_dist_add => _NODISCARD (and remove comments)
* is_permutation => _NODISCARD
* Add yvals_core.h comments.
* Delete unused _Copy_n_core and TRANSITION, DevCom-889321 comment.
* Put the comments in the right place and remove phantom braces.
* Optimize the is_permutation family and _Hash::operator== for multicontaniers slightly.
<xutility>
4660: _Find_pr is a helper for is_permutation, so move it down to that area.
4684: The SHOUTY banners were attached to functions which were implmentation details of is_permutation, so I fixed them up to say is_permutation and removed the banners for helper functions.
4711: Use if constexpr to avoid a tag dispatch call for _Trim_matching_suffixes. Optimizers will like this because they generally hate reference-to-pointer, and it also serves to workaround DevCom-883631 when this algorithm is constexprized.
4766: Indicate that we are trimming matching prefixes in this loop body, and break apart comment block that was incorrectly merged by clang-format.
4817: In the dual range forward version of the algorithm, calculate the distances concurrently to avoid wasting lots of time when the distances vary by a lot. For example, is_permutation( a forward range of length 1, a forward range of length 1'000'000 ) used to do the million increments, now it stops at 1 increment.
4862: In the dual range random-access version, avoid recalculating _Last2 when it has already been supplied to us.
<xhash>
1404: Move down construction of _Bucket_hi in _Equal_range to before the first loop body using it.
1918: Added a new function to calculate equality for unordered multicontainers. We loop over the elements in the left container, find corresponding ranges in the right container, trim prefixes, then dispatch to is_permutation's helper _Check_match_counts.
Improvements over the old implementation:
* For standard containers, we no longer need to hash any elements from the left container; we know that we've found the "run" of equivalent elements because we *started* with an element in that container. We also never go "backwards" or multiply enumerate _Left (even for !_Standard), which improves cache use when the container becomes large.
* Just like the dual range is_permutation improvement above, when the equal_ranges of the containers are of wildly varying lengths, this will stop on the shorter of the lengths.
* We avoid the 3-arg is_permutation doing a linear time operation to discover _Last2 that we already had calculated in determining _Right's equal_range.
The function _Multi_equal_check_equal_range tests one equal_range from the left container against the corresponding equal_range from the right container, while _Multi_equal invokes _Multi_equal_check_equal_range for each equal_range.
Performance results:
```
Benchmark Before (ns) After (ns) Percent Better
HashRandomUnequal<unordered_multimap>/1 18.7 11.7 59.83%
HashRandomUnequal<unordered_multimap>/10 137 97 41.24%
HashRandomUnequal<unordered_multimap>/100 1677 1141 46.98%
HashRandomUnequal<unordered_multimap>/512 10386 7036 47.61%
HashRandomUnequal<unordered_multimap>/4096 173807 119391 45.58%
HashRandomUnequal<unordered_multimap>/32768 2898405 1529710 89.47%
HashRandomUnequal<unordered_multimap>/100000 27441112 18602792 47.51%
HashRandomUnequal<hash_multimap>/1 18.9 11.8 60.17%
HashRandomUnequal<hash_multimap>/10 138 101 36.63%
HashRandomUnequal<hash_multimap>/100 1613 1154 39.77%
HashRandomUnequal<hash_multimap>/512 10385 7178 44.68%
HashRandomUnequal<hash_multimap>/4096 171718 120115 42.96%
HashRandomUnequal<hash_multimap>/32768 3352231 1510245 121.97%
HashRandomUnequal<hash_multimap>/100000 26532471 19209741 38.12%
HashRandomEqual<unordered_multimap>/1 16 9.4 70.21%
HashRandomEqual<unordered_multimap>/10 126 89.2 41.26%
HashRandomEqual<unordered_multimap>/100 1644 1133 45.10%
HashRandomEqual<unordered_multimap>/512 10532 7183 46.62%
HashRandomEqual<unordered_multimap>/4096 174580 120029 45.45%
HashRandomEqual<unordered_multimap>/32768 3031653 1455416 108.30%
HashRandomEqual<unordered_multimap>/100000 26100504 19240571 35.65%
HashRandomEqual<hash_multimap>/1 15.9 9.38 69.51%
HashRandomEqual<hash_multimap>/10 123 94.1 30.71%
HashRandomEqual<hash_multimap>/100 1645 1151 42.92%
HashRandomEqual<hash_multimap>/512 10177 7144 42.46%
HashRandomEqual<hash_multimap>/4096 172994 121381 42.52%
HashRandomEqual<hash_multimap>/32768 3045242 1966513 54.85%
HashRandomEqual<hash_multimap>/100000 26013781 22025482 18.11%
HashUnequalDifferingBuckets<unordered_multimap>/2 5.87 3.41 72.14%
HashUnequalDifferingBuckets<unordered_multimap>/10 12 3.39 253.98%
HashUnequalDifferingBuckets<unordered_multimap>/100 106 3.41 3008.50%
HashUnequalDifferingBuckets<unordered_multimap>/512 691 3.46 19871.10%
HashUnequalDifferingBuckets<unordered_multimap>/4096 6965 3.47 200620.46%
HashUnequalDifferingBuckets<unordered_multimap>/32768 91451 3.46 2642992.49%
HashUnequalDifferingBuckets<unordered_multimap>/100000 290430 3.52 8250752.27%
HashUnequalDifferingBuckets<hash_multimap>/2 5.97 3.4 75.59%
HashUnequalDifferingBuckets<hash_multimap>/10 11.8 3.54 233.33%
HashUnequalDifferingBuckets<hash_multimap>/100 105 3.54 2866.10%
HashUnequalDifferingBuckets<hash_multimap>/512 763 3.46 21952.02%
HashUnequalDifferingBuckets<hash_multimap>/4096 6862 3.4 201723.53%
HashUnequalDifferingBuckets<hash_multimap>/32768 94583 3.4 2781752.94%
HashUnequalDifferingBuckets<hash_multimap>/100000 287996 3.43 8396284.84%
```
Benchmark code:
```
#undef NDEBUG
#define _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS
#include <assert.h>
#include <benchmark/benchmark.h>
#include <hash_map>
#include <random>
#include <stddef.h>
#include <unordered_map>
#include <utility>
#include <vector>
using namespace std;
template <template <class...> class MapType> void HashRandomUnequal(benchmark::State &state) {
std::minstd_rand rng(std::random_device{}());
const auto range0 = static_cast<ptrdiff_t>(state.range(0));
vector<pair<unsigned, unsigned>> testData;
testData.resize(range0 * 5);
const auto dataEnd = testData.begin() + range0;
std::generate(testData.begin(), dataEnd, [&]() { return pair<unsigned, unsigned>{rng(), 0u}; });
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd, std::copy(testData.begin(), dataEnd, dataEnd))));
std::unordered_multimap<unsigned, unsigned> a(testData.begin(), testData.end());
testData.clear();
std::unordered_multimap<unsigned, unsigned> b = a;
next(b.begin(), b.size() - 1)->second = 1u;
for (auto &&_ : state) {
(void)_;
assert(a != b);
}
}
BENCHMARK_TEMPLATE1(HashRandomUnequal, unordered_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
BENCHMARK_TEMPLATE1(HashRandomUnequal, hash_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
template <template <class...> class MapType> void HashRandomEqual(benchmark::State &state) {
std::minstd_rand rng(std::random_device{}());
const auto range0 = static_cast<ptrdiff_t>(state.range(0));
vector<pair<unsigned, unsigned>> testData;
testData.resize(range0 * 5);
const auto dataEnd = testData.begin() + range0;
std::generate(testData.begin(), dataEnd, [&]() { return pair<unsigned, unsigned>{rng(), 0}; });
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd, std::copy(testData.begin(), dataEnd, dataEnd))));
std::unordered_multimap<unsigned, unsigned> a(testData.begin(), testData.end());
testData.clear();
std::unordered_multimap<unsigned, unsigned> b = a;
for (auto &&_ : state) {
(void)_;
assert(a == b);
}
}
BENCHMARK_TEMPLATE1(HashRandomEqual, unordered_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
BENCHMARK_TEMPLATE1(HashRandomEqual, hash_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
template <template <class...> class MapType> void HashUnequalDifferingBuckets(benchmark::State &state) {
std::unordered_multimap<unsigned, unsigned> a;
std::unordered_multimap<unsigned, unsigned> b;
const auto range0 = static_cast<ptrdiff_t>(state.range(0));
for (ptrdiff_t idx = 0; idx < range0; ++idx) {
a.emplace(0, 1);
b.emplace(1, 0);
}
a.emplace(1, 0);
b.emplace(0, 1);
for (auto &&_ : state) {
(void)_;
assert(a != b);
}
}
BENCHMARK_TEMPLATE1(HashUnequalDifferingBuckets, unordered_multimap)->Arg(2)->Arg(10)->Range(100, 100'000);
BENCHMARK_TEMPLATE1(HashUnequalDifferingBuckets, hash_multimap)->Arg(2)->Arg(10)->Range(100, 100'000);
BENCHMARK_MAIN();
* Apply a bunch of code review comments from Casey.
* clang-format
* Apply @miscco's code deduplication idea for <xhash>.
* Fix code review comments from Stephan: comments and add DMIs.
This change is not a statement of support for the Intel C++ compiler by the STL, so much as an attempt to not break it gratuitously.
Fixes DevCom-744112.
* Implement P0357R3
* Update LLVM to get skip of libcxx\test\std\utilities\function.objects\refwrap\weak_result.pass.cpp, and exclude "// REQUIRES: c++98 || c++03 || c++11 || c++14 || c++17" as a 'magic comment'.
Co-authored-by: Billy O'Neal <billy.oneal@gmail.com>
Co-authored-by: Casey Carter <cartec69@gmail.com>
...which renames the feature-test macro `__cpp_lib_nothrow_convertible` to `__cpp_lib_is_nothrow_convertible`. We *just* added this feature-test macro which hasn't yet shipped, and therefore want to rename it quickly - ideally before customers notice it exists. LWG has tentatively approved this issue resolution.
This calls `abort()` as there's no need to invoke the terminate handler.
(This is a virtual function, so eliminating it entirely would risk ODR
violations leading to crashes. It's much safer to provide a definition
that can't be called.)
Additionally, fix `<xlocale>` to qualify `_CSTD abort()`.
While we must continue to support `msvcp140.dll` running on Windows XP,
we don't need to support compiling our headers with the (removed)
`v140_xp` toolset and its corresponding old Windows SDK. Accordingly,
we can unconditionally define `shared_mutex`. (This is a C++17 feature,
but it was implemented before Standard modes, so it's not guarded by
`_HAS_CXX17`.)
Currently, we're building the STL in both our Microsoft-internal MSVC
repo and in GitHub, as we work on the migration. The MSVC repo uses a
checked-in compiler (the "toolset") to build the STL and the compiler
itself. Earlier, the checked-in toolset identified itself as
19.25.28318.97 but lacked support for `is_constant_evaluated`, so we
needed to detect that exact version number. Now, the toolset has been
updated, so this workaround is no longer necessary.
When VS 2019 16.5 Preview 2 is available in the future, we'll begin
requiring it to build the GitHub sources, at which point we'll be able
to unconditionally define `__cpp_lib_is_constant_evaluated`.
* Avoid burning unused stack space for a T in _List_node_insert_op. Resolves#973579 and GH-365.
* Change forward_list to follow a similar pattern for consistency.
* First round of code review feedback.
Permanently work around DevCom-848104 by simplifying hash_meow::value_type. This is what unordered_meow::value_type already does, which is why that can already use int = 0 SFINAE.
* Fix#272: `<future>: promise<_Ty&>::set_value(_Ty& _Val)` should use `_STD addressof(_Val)`
* Fix#344: `<yvals_core.h>`: Update `_MSVC_STL_UPDATE` to December 2019
Adam Bucior
Charles Milette
Jean Philippe
statementreply
Michael Schellenberger Costa
Billy O'Neal
Casey Carter
Stephan T. Lavavej
Pavol Misik
Daniil Goncharov
Daniel Marshall
Casey Carter
Michael Schellenberger Costa
Nikita Kniazev
Charlie Barto
Julie Philip James
SasLuca