zip_iterator::value_type should not be reference

[anonymous]

hi, defining zip_iterator::value_type in the boost.iterator library to be the same as the reference type breaks some mutating algorithms on zip_iterators. for example sort:

template<class Array1,class Array2>
void array_multisort(Array1& array1, Array2& array2)
{
  using namespace boost;
  std::sort(make_zip_iterator(make_tuple(array1.begin(), array2.begin())),
	    make_zip_iterator(make_tuple(array1.end(), array2.end())));
}

won't work as expected. Patching zip_iterator to provide a more natural value_type makes the above code work as intended. The patch is attached to this message.

mfg thomas

[Steven Watanabe]

This looks like a duplicate of #973.

[Mathias Gaunard]

Is there any reason not to merge this patch? zip_iterator compiles the above code but produces erroneous output, that's a pretty important bug.

If there is a problem with this patch, please let me know what needs to be improved.

[Dave Abrahams]

One reason is that I don't have a testcase that is actually reliable. You see, zip_iterator can't be a legit C++03 Forward Iterator, since its reference type is not a real reference. Therefore, the standard library has a right to refuse to compile the example you gave even without the patch. It may work on your installation and legitimately break somewhere else.

So, if you could build a testcase that doesn't rely on strict Forward Iterator conformance, but instead captures the assumptions that your std::sort implementation is making, that make this work, I'd be more than happy to accept the patch as a QOI improvement.

A smaller issue is the definition of iterator_value_type is redundant with iterator_value in <boost/iterator/iterator_traits.hpp>

Thanks for your efforts and patience on this one.