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