Subject: Re: [boost] Boost range - Add variadic join/zip
From: Neil Groves (neil_at_[hidden])
Date: 2013-05-10 15:39:23
On Fri, May 10, 2013 at 3:31 PM, Jeff Flinn <Jeffrey.Flinn_at_[hidden]> wrote:
> On 5/10/2013 8:44 AM, Jonathan Wakely wrote:
>> On 10 May 2013 12:55, Neil Groves wrote:
>>> On Fri, May 10, 2013 at 11:28 AM, Jonathan Wakely
>>>> 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
>>>> I like being able to avoid the cost of checking for the end of every
>>> 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.
> The closest existing practice I see is the std::mismatch algorithm which
> requires the first of the two input sequences to be the longest, and only
> checks first1 != last1.
> boost::range::mismatch pays the overhead of checking both input sequence
> iterators against their corresponding end iterators.
It does indeed pay the price under all circumstances with no option to
opt-out. This is my design error. I have a renewed effort on obeying the
zero-overhead principle in the last year or so. I've found design decisions
in libraries that I have used to not provide zero-overhead options
extremely limiting. I shall go back and review all of the Boost.Range code
and provide zero-overhead options wherever I have failed to do so.
For a zip iterator, of course, the overhead could be considerably greater
depending on how many ranges were zipped together. I don't believe there is
a need for me to choose the right solution for my clients. It's trivial to
> Perhaps the std::mismatch approach is appropriate for zip iterator as
> well. In accommodating std::mismatch requirements when I don't know that
> the first sequence is longest I've a wrapped mismatch that check's the
> sizes and swaps argument references, though this is limited in it's
Ah yes this comes back to the boost::size modifications I also have to do!
I could utilise an optimised boost::size() that provides O(1) for
containers such as list to provide optimised implementations under more
scenarios. It looks like I've got some work to do!
Thank you for pointing this out since I had honestly forgotten that I'd
made this design decision for mismatch.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk