Re: [hub] on the specialized iteration over elements
Joaquin M López Muñoz via Boost <[email protected]>
| Newsgroups | gmane.comp.lib.boost.devel |
|---|---|
| Message-ID | <[email protected]> |
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.
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/Z3BHVPAKXYLHEWPFTU3GN5XT2JDHKNKB/