Date: Sat, 16 Dec 2023 21:40:14 +0800
Hi fellow C++ experts,
I am frustrated that the following code cannot be compiled:
std::list l{0, 0, 1, 2, 3, 0, 0};
auto subrange = std::ranges::search(l, std::vector{1, 2, 3});
std::cout << subrange.size() << "\n";
The problem is that currently if a subrange is returned in <ranges>/
<algorithm>, it is constructed in the form of subrange{it1, it2}, even
though we have increment from it1 to it2, which means we already know how
far is it1 from it2.
I'm curious if it would be more valuable if we returned subrange{it1, it2,
d}, although this might introduce an extra variable d to track the
distance. The advantage of this is that the returned subranges are always
sized_range, which makes the corresponding algorithm return more
information.
In <ranges>, some views like split_view or chunk_view can also benefit from
this because the subrange they split will always be a sized_range.
What do you think? Is this worth considering as an enhancement? Or is this
a bad idea?
Hewill
I am frustrated that the following code cannot be compiled:
std::list l{0, 0, 1, 2, 3, 0, 0};
auto subrange = std::ranges::search(l, std::vector{1, 2, 3});
std::cout << subrange.size() << "\n";
The problem is that currently if a subrange is returned in <ranges>/
<algorithm>, it is constructed in the form of subrange{it1, it2}, even
though we have increment from it1 to it2, which means we already know how
far is it1 from it2.
I'm curious if it would be more valuable if we returned subrange{it1, it2,
d}, although this might introduce an extra variable d to track the
distance. The advantage of this is that the returned subranges are always
sized_range, which makes the corresponding algorithm return more
information.
In <ranges>, some views like split_view or chunk_view can also benefit from
this because the subrange they split will always be a sized_range.
What do you think? Is this worth considering as an enhancement? Or is this
a bad idea?
Hewill
Received on 2023-12-16 13:40:26