zip_iterator does not support std::tuple and std::pair

[claas.koehler@…]

The boost zip_iterator is not compatible with std::tuple and std::pair

The proposed patch solves this problem.

Note that I copied some more general tuple algorithms I created for another project. These are all included in the newly introduced namespace helper. Maybe they can be rewritten using boost::mpl, but since I am not familiar with it I used the existing code.

Furthermore I encountered the problem, that a specialisation of the template functions in namespace tuple_impl_specific does not work, if this is done outside zip_iterator.hpp. The reason appears to be, that the user overloads are not known to the compiler, when the functions are called. This may be a problem, if users want to specialise for their own tuple class. To overcome this difficulty, I replaced the template functions by template classes, which seem to work even if specialisations are made outside zip_iterator.hpp

[claas.koehler@…]

diff of the patched zip_iterator file compared to the 1.50.0 version

[claas.koehler@…]

diff of the patched zip_iterator file compared to the 1.50.0 version

[Kohei Takahashi <flast@…>]

How about use Boost.Fusion instead of Boost.Tuple? I'll attach 5 patches.

First, bug7513.patch fixes #7513.
boost_tuple-convert.patch adapts Boost.Tuple to Boost.MPL algorithms via Boost.Fusion.
std_tuple-convert.patch similar to above one, but for std::tuple.
zip_iterator.patch is main patch of this changes: rebase impl of zip_iterator to Boost.Fusion.
Finally, std_pair-specialization.patch is specialization for std::pair.

This changes have backward compatibility: iterator/zip_iterator.hpp includes fusion/adapted/boost_tuple.hpp implicitly.

[Dave Abrahams]

FYI, there's a branch or tag somewhere way back in SVN history that does (mostly) the same thing. At the time, I think there were reasons not to apply it, and by now it's probably out-of-sync with Fusion in some subtle way, but it was well-organized at least, so it might be worth a look if you can find it.

[jeffrey.hellrung]

Re Fusion, I was thinking the same thing. Will have to take a closer look at the patches in the future to see if they align with what I'm thinking. And thanks for the FYI, Dave.

[Aditya Ramesh <_@…>]

Is there a target version for which these patches will be applied? Compatibility with std::tuple would be a very important feature to have, especially since compiler support for C++11 is now more widespread.

[anonymous]

Is there an ETA for when this gets applied?

[Kohei Takahashi <flast@…>]

Which do you think is better, claas.koehler's patch or Re Fusion?

[claas.koehler@…]

I think the general agreement was, that the Fusion Patch is preferable, since my patch constitutes a quick and dirty solution only. That's why I never took any further attempts in submitting tests.

However, since the Fusion patch has not been released, I have been using my version privately for quite a while now and patched every version of my local boost, because I require the functionality in several projects. I would prefer to stop doing this as soon as possible, of course.

Maybe it would be good to poll in boost devel mailing list, why the patch has not been applied so far and then take the necessary steps to finally get it into production.

My personal preference would be to apply Kohei Takashi's patch with the necessary testing, if it is working, regardless of any other old versions (see Jeffrey's comment 20 months ago). A good solution today is definitely better than a perfect one in another 20 months from my point of view.

Regards Claas

[Kohei Takahashi <flast@…>]

OK. Now, I'm working for reimplementing zip_iterator as fusion based one in following branches.

ttps://github.com/Flast/fusion/tree/pr/adapt/tuple
ttps://github.com/Flast/iterator/tree/pr/zip_iterator/fusionize

However, I have no idea for fusion::convert for non variadic template based std::tuple (i.e. msvc 11.0 or earlier). So, I will spent a little time to send PR.

[Kohei Takahashi <flast@…>]

I've submitted about Fusion based zip_iterator. Please review it.

​https://github.com/boostorg/iterator/pull/2

[Edward Diener]

I have looked at the PR but found a problem when using the fusion container deque. Please take a look at my comments in the PR. I would like to move ahead with the PR, as I think it is valuable to allow this change, but I need a clarification of why it is failing with the fusion deque.

[edaskel@…]

Looks like this has been fixed :) Close?

[Edward Diener]

Yes, this has been fixed and should appear in upcoming release.

[anonymous]

up

[edaskel@…]

Let's close this "fixed" :)