Various cleanups: Impl and wrapper functions for vector algorithms #4146
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AlexGuteniev
approved these changes
Nov 4, 2023
|
I am a greedy kitty who's speculatively mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
CaseyCarter
approved these changes
Nov 6, 2023
| @@ -9848,7 +9850,7 @@ namespace ranges { | |||
| if (!_STD is_constant_evaluated()) { | |||
| const auto _First_ptr = _STD to_address(_First); | |||
| const auto _Last_ptr = _First_ptr + (_Last - _First); | |||
| const auto _Result = _CSTD __std_minmax_element(_First_ptr, _Last_ptr); | |||
| const auto _Result = _STD __std_minmax_element(_First_ptr, _Last_ptr); | |||
There was a problem hiding this comment.
Should we remove _std_ from these function names - possibly in a followup - to avoid the awkward _STD __std?
There was a problem hiding this comment.
The idea is that they behave just like the __std_meow_N functions without the N size; renaming them would break that symmetry. That said I wouldn't grumble too much, as long as the names are unique.
(If I had my way there wouldn't be any _STD at all and we wouldn't care about the incomplete type scenario 😹)
| @@ -94,6 +94,7 @@ const void* __stdcall __std_max_element_4(const void* _First, const void* _Last, | |||
| const void* __stdcall __std_max_element_8(const void* _First, const void* _Last, bool _Signed) noexcept; | |||
| _END_EXTERN_C | |||
|
|
|||
| _STD_BEGIN | |||
| template <class _Ty, class _TVal> | |||
| __declspec(noalias) size_t __std_count_trivial(_Ty* _First, _Ty* _Last, const _TVal _Val) noexcept { | |||
This was referenced Nov 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First,
vector_algorithms.cppwas defining functions within an unnamed namespace that were quasi-shadowing wrapper functions in<algorithm>and<xutility>:STL/stl/src/vector_algorithms.cpp
Lines 1440 to 1442 in f392449
STL/stl/inc/xutility
Lines 97 to 98 in f392449
This was incredibly confusing, so I'm renaming the
vector_algorithms.cppfunctions toimpl. (I say it was "quasi"-shadowing because we never dragged them into the same scope, but we should never use the same names for things with different signatures/purposes like this. There are specific scenarios where function overloading is fine - usually when the compiler will handle types/arity and there's no risk of confusion about "which one" we're getting - and this is not such a scenario, so we should use different names.)Next, this moves
<algorithm>and<xutility>'s vector algorithm wrapper templates (that handle 1/2/4/8-byte dispatching) from the global namespace tostd. I noticed this while auditing the STL for namespace discipline - aside fromextern "C"machinery in the global namespace, the STL is almost always careful to define all of its internal machinery withinstd. (There are a few special exceptions for bitmask ops.) These wrapper templates were a major exception. I'm keeping their names, since they do strongly resemble theextern "C"functions they're wrapping, but we should move them intostdfor cleanliness (and because this may make later work more convenient for me).