On Fri, May 10, 2013 at 11:28 AM, Jonathan Wakely
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
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