Refactor ranges::minmax and ranges::minmax_element #3384
Merged
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.
The fix for #2900 in #3366 did not take advantage of the fact that the minimum and maximum elements of a range are always distinct except when the range has only one element. It couldn't easily do so due to the way
ranges::minmax
andranges::minmax_element
share the common backendranges::_Minmax_element_unchecked
.This PR introduces a new backend for
ranges::minmax
(ranges::_Minmax_fn::_Minmax_fwd_unchecked
) and makesranges::_Minmax_element_unchecked
the private memberranges::_Minmax_element_fn::_Minmax_element_fwd_unchecked
. Since the two are distinct,_Minmax_fwd_unchecked
can deal in values instead of iterators, and we can unroll the first loop iteration to detect the single-element case naturally. Since no additional branch is needed, we can enable the fix for #2900 unconditionally.Drive-by: Fully qualify the names of ugly functions called by
ranges::minmax
andranges::minmax_element
.