Re: [boost] Boost range - Add variadic join/zip

Subject: Re: [boost] Boost range - Add variadic join/zip
From: Neil Groves (neil_at_[hidden])
Date: 2013-05-10 07:55:21

On Fri, May 10, 2013 at 11:28 AM, Jonathan Wakely
<jwakely.boost_at_[hidden]>wrote:

> On 9 May 2013 16:01, Gonzalo BG wrote:
> > A variadic zip is more complicated. If we want write access we cannot use
> > boost zip_iterator. Still one can use Anthony Williams' TupleIterator:
> >
> > template <class... T>
> > auto zip(T&&... c)
> > -> boost::iterator_range<
> >
> >
> decltype(iterators::makeTupleIterator(std::begin(std::forward<T>(c))...))> {
> >   return boost::make_iterator_range
> >       (iterators::makeTupleIterator(std::begin(std::forward<T>(c))...),
> >        iterators::makeTupleIterator(std::end(std::forward<T>(c))...));
> > }
> >
> > For read-only access one could use boost::zip_iterator, but I think
> > write-access is _really_ important (e.g. sort wouldn't work).
>
> It looks as though it's undefined behaviour to zip ranges of different
> lengths, because you'll walk off the end of the shorter ranges.
>
My variadic zip stops at the end of the shortest range, which seems to
> be consistent with zip functions in most other languages I've looked
> at.
>
>
I like being able to avoid the cost of checking for the end of every item
in the zip especially for non-random access iterators. In anything I put
into Boost.Range I think it of paramount importance to obey the zero
overhead principle. It seems that it would be simple to allow both end
detection mechanisms.

> Your adaptors also get dangling references if used with rvalue ranges,
> although this is a problem with the existing boost range adaptors too.
>

Yes, this has come up numerous times. It's a problem far beyond just ranges
and range adaptors. Knowing you a little, I suspect you have a solution I
have not thought of to better deal with the issue.

Is the variadic zip iterator you implemented public?

Thanks,
Neil Groves