Date: Fri, 5 Jun 2026 20:40:40 +0800
Rainer Deyke via Std-Proposals <std-proposals_at_[hidden]> 於
2026年6月5日週五 下午6:09寫道:
> An annoyance with equal_range on [unordered] associative containers:
>
> Associative containers have an equal_range member function that returns
> a std::pair of iterators, which is not a range (as defined by
> std::ranges::range) and cannot be iterated over directly.
>
> The standard library provides no easy way to convert a pair of iterators
> into a range.
>
> ranges::equal_range does provide a true range, but it has terrible
> performance for associative containers without random access iterators,
> and it produces undefined behavior (usually in the form of incorrect
> results) on unordered associative containers.
>
> There are several ways this could be fixed:
>
> An additional member function (true_equal_range?) could be added to the
> existing [unordered] associative containers. This is less than ideal
> because it leaves user-defined [unordered] associative containers behind.
>
> Overloads for std::begin and std::end could be added for std::pairs of
> iterators. This would be my preferred solution, but it could break
> existing code. It also prevents treating std::pair<T, T> as a range of
> two elements of type T.
>
> A constructor that takes a std::pair of iterators could be added to
> std::ranges::subrange. This should be a fairly safe addition to the
> standard, although it can break user code in pathological cases.
>
> Add a free function to convert a std::pair of iterators into a
> std::ranges::subrange. This is the safest solution; highly unlikely to
> break user code and any user code it does breaks is the fault of the user.
>
>
Yep, but it can be done very easily with:
auto to_subrange = [](auto&&... iters) { return
std::ranges::subrange(iters...); };
auto subrange = std::apply(to_subrange, m.equal_range(1));
> Code could be added to ranges::equal_range to handle [unordered]
> associative containers correctly. Although this sounds good in theory,
> in practice it may not be possible to verify that the ordering passed to
> ranges::equal_range is the same as the ordering used by the container.
>
>
> --
> Rainer Deyke - rainerd_at_[hidden]
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
2026年6月5日週五 下午6:09寫道:
> An annoyance with equal_range on [unordered] associative containers:
>
> Associative containers have an equal_range member function that returns
> a std::pair of iterators, which is not a range (as defined by
> std::ranges::range) and cannot be iterated over directly.
>
> The standard library provides no easy way to convert a pair of iterators
> into a range.
>
> ranges::equal_range does provide a true range, but it has terrible
> performance for associative containers without random access iterators,
> and it produces undefined behavior (usually in the form of incorrect
> results) on unordered associative containers.
>
> There are several ways this could be fixed:
>
> An additional member function (true_equal_range?) could be added to the
> existing [unordered] associative containers. This is less than ideal
> because it leaves user-defined [unordered] associative containers behind.
>
> Overloads for std::begin and std::end could be added for std::pairs of
> iterators. This would be my preferred solution, but it could break
> existing code. It also prevents treating std::pair<T, T> as a range of
> two elements of type T.
>
> A constructor that takes a std::pair of iterators could be added to
> std::ranges::subrange. This should be a fairly safe addition to the
> standard, although it can break user code in pathological cases.
>
> Add a free function to convert a std::pair of iterators into a
> std::ranges::subrange. This is the safest solution; highly unlikely to
> break user code and any user code it does breaks is the fault of the user.
>
>
Yep, but it can be done very easily with:
auto to_subrange = [](auto&&... iters) { return
std::ranges::subrange(iters...); };
auto subrange = std::apply(to_subrange, m.equal_range(1));
> Code could be added to ranges::equal_range to handle [unordered]
> associative containers correctly. Although this sounds good in theory,
> in practice it may not be possible to verify that the ordering passed to
> ranges::equal_range is the same as the ordering used by the container.
>
>
> --
> Rainer Deyke - rainerd_at_[hidden]
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2026-06-05 12:40:56
