Re: [hub] on the specialized iteration over elements

On Fri, Apr 17, 2026, 09:43 Joaquin M López Muñoz <
[email protected]> wrote:

> El 16/04/2026 a las 21:42, Andrzej Krzemienski escribió:
> > Hi Everyone,
> > Once again, thank you Joaquín for this contribution to the community.
> >
> > This is not really a review, but I wanted to talk about this idea to
> > implement a specialized algorithm for iterating over the container
> > elements in the form of hub::visit.
> >
> > First, should we draw from this a more general observation that
> > iterators are an abstraction with overhead, and other containers
> > (deque?) would also benefit from this inversion-of-control approach?
>
>
> Ion has aready followed up on this subtopic, I'll add my observations on
> that subthread.
>
>
> >
> > Second, I think that the most natural naming choice for this operation
> > is "for each", not "visit". It does practically the same thing as
> > `std::for_each`.
> >
> > Third, the interface is rather unusual, and it allows one hub to
> > iterate over another hub's elements:
> >
> > hub<T> h, g;
> > h.visit(g.begin(), g.end(), fun);
> >
> > https://godbolt.org/z/bbb765bb1
> >
> > It looks like this function should be a free function rather than a
> > member function. And if there is a reason to make it a member
> > function, at minimum add a precondition that both the iterators should
> > point inside the container.
>
>
> Yes, I think your proposal makes sense, since, as you CE snippet shows,
> the operation can be performed based on the iterators alone.
>
> So, instead of visit and visit_all we can have global functions:
>
>    template<hub_iterator Iterator, typename F>
>    Iterator for_each(Iterator first, Iterator last, F f);
>
>    template<typename T, typename Allocator, typename F>
>    typename hub<T, Allocator>::iterator for_each(hub<T, Allocator>& x, F f)
>    {
>      return for_each(x.begin(), x.end(), std:.ref(f));
>    }
>
>    // same for const hub
>
> I have a bikeshedding problem with visit_while/visit_all_while, though:
> the morally closest function in <algorithm> would be std::find_if_not,
> which is not a very intuitive equivalent and has, in fact, different
> semantics (predicates can't change the passed element). Ideas on naming?
> for_each_while would be my first option, I guess.
>

A very good and descrptive name, IMO.

Regards,
&rzej;

>
> Joaquín M López Muñoz
>
>
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/HX5AZTLLQCGIEFKQKMT6K2XT376CP7I5/