https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123211
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppalka at gcc dot gnu.org
--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Segmented iterator concept implemented and enabled for join_view, concat_view
and deque. We took a callback-style approach for the API instead of more
fundamental primitives (like in https://lafstern.org/matt/segmented.pdf) for
various reasons, see
https://gcc.gnu.org/pipermail/gcc-patches/2026-July/723822.html.
> Cause distance(transform_view) should just be distance(transform_view.base())
> too, cause otherwise distance(... | join | transform(f)) is slow.
Would it make sense to recognize transform_view iterators as segmented if the
underlying iterator is?
> And then distance(filter_view) could just loop internally.
> And distance(r | stride(k)) can be ceil(distance(r) / k), or something along
> those lines.
These I think would need to be implemented as separate optimizations.
