[Bug libstdc++/108823] ranges::transform could be smarter with two sized ranges

2025-02-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823 --- Comment #3 from Jonathan Wakely --- Or decltype(ranges::size(r1) + ranges::size(r2)) ?

[Bug libstdc++/108823] ranges::transform could be smarter with two sized ranges

2025-02-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823 --- Comment #2 from Jonathan Wakely --- Is std::min(ranges::size(__r1), ranges::size(__r2)) safe? Probably not, since we could have iota(0LL, LLONG_MAX) on a 32-bit host where size_t is 32-bit. So I suppose it should be uintmax_t instead.

[Bug libstdc++/108823] ranges::transform could be smarter with two sized ranges

2025-02-26 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823 --- Comment #1 from Jonathan Wakely --- So maybe something like: --- a/libstdc++-v3/include/bits/ranges_algo.h +++ b/libstdc++-v3/include/bits/ranges_algo.h @@ -758,11 +758,21 @@ namespace ranges _Out __result, _Fp __binary_op,

[Bug libstdc++/108823] ranges::transform could be smarter with two sized ranges

2023-02-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|