https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
Bug ID: 100070
Summary: Standard library container iterator-pair constructors
should check C++20 iterator concepts
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
>From StackOverflow (https://stackoverflow.com/q/67081354/2069064), a user was
benchmarking code that did this:
int convert(int);
std::vector<int> foo(100,42);
auto transform_range = foo | std::ranges::views::transform(convert);
std::vector<int> fooTimesTwo(transform_range.begin(),
transform_range.end());
And found it to be much slower than their initial implementation that did not
use ranges. This is because while transform_range is a C++20 random access
range, it is only a C++17 input range.
libstdc++'s decision is based entirely on iterator_category
(https://github.com/gcc-mirror/gcc/blob/8084ab15a3e300e3b2c537e56e0f3a1b00778aec/libstdc%2B%2B-v3/include/bits/stl_vector.h#L652-L659)
which does the best you can with an input range: just loop and emplace.
But if it instead checked for forward_iterator and random_access_iterator (the
concept), this construction case could be handled efficiently (i.e. as a single
allocation). I think that should safe? Checking for random_access_iterator
checks the tag before checking for the validity of operator-?
