[libc++] Add segmented iterator optimizations to more algorithms

[philnik777]

We have a few algorithms which are optimized for segmented iterators, but a lot aren't yet. These algorithms would most likely benefit from adding such an optimization:

• count_if
• count (should probably forward to count_if)
• equal
• fill
• fill_n (should probably forward to fill or the other way around)
• fold_left_with_iter
• for_each_n (Should probably forward to for_each)
• generate
• generate_n (should probably forward to generate)
• lexicographical_compare
• ranges::min (range overload)
• ranges::max (range overload)
• ranges::minmax (range overload)
• mismatch
• replace (should probably forward to replace_if)
• replace_if
• replace_copy (should probably forward to replace_copy_if)
• replace_copy_if
• reverse_copy
• swap_ranges
• transform
• distance

[NoumanAmir657]

Can I work on this?

[philnik777]

Can I work on this?

Sure. Just pick one and make a patch.

[NoumanAmir657]

Okay. Working on 'fill'.

[adeel10x]

Hi @philnik777, I want to work on these too. I have started working on count_if and will create a PR very soon.

[correaa]

How the algorithm know that is can exploit segmented iterators now?

because they specialize on iterator type (e.g. deque iterator argument) or is there a protocol/trait/detection mechanism?

Can I bring my own external segmented iterator or it has to be known by the library already?

[philnik777]

How the algorithm know that is can exploit segmented iterators now?

because they specialize on iterator type (e.g. deque iterator argument) or is there a protocol/trait/detection mechanism?

Can I bring my own external segmented iterator or it has to be known by the library already?

Currently this is just library-internal special magic. We have __segmented_iterator_traits, but that's not for public use. I think supporting this for user-defined types would require a proposal to WG21. If you really want to you can use views::join to get the optimization that way though (assuming you have C++20).