<boost/fusion/algorithm/transformation/push_back.hpp> is broken

[sefi@…]

I get an error when only including the push_back header with using boost-1.48.0_beta1. It used to work with boost-1.47.0.

[Joel de Guzman]

Eric, could you please have a quick check?

The error points me to:

C:\dev\boost\boost/fusion/view/iterator_range/detail/segmented_iterator_range.hpp(261) : error C2146: syntax error : missing ',' before identifier 'push_back'

I'm not familiar enough with segmented_iterator.

Thanks!

[Eric Niebler]

The problem is simple, and the fix is also simple but tedious and requires discipline. The problem is circular includes. It's nearly impossible to avoid. Consider that fusion::begin should automatically return a segmented_iterator for segmented sequences. But the implementation of segmented_iterator itself need to use fusion::begin() to find the start iterator of the sequence's internal segments. Hence, you end up with a circular dependency: begin.hpp needs segmented_iterator, but segmented_iterator.hpp needs begin. In this case, it's the fact that segmented_iterator's implementation uses push_back, which uses joint_view, which uses begin, which uses segmented_iterator, closing the circle.

The solution is consistent use of _fwd.hpp headers. Every .hpp gets an associated _fwd.hpp that forward-declares the things it publishes. The _fwd.hpp must do nothing but forward-declare stuff and include other _fwd.hpp headers. Then, for instance, foo.hpp includes foo_fwd.hpp before it includes anything else. When you do that consistently, circular includes happen, but they never lead to this strange situation where a file appears to be included but its symbols are not visible -- as is happening here.

In Proto, I solve this problem by having one big proto_fwd.hpp file that forward-declares everything in Proto. That gets included from every other file in Proto. Once that's done, headers are free to include each other willy-nilly and the circular include problem is vanquished. You may choose to do something similar, or individual _fwd.hpp headers, or maybe granular ones like algorithm_fwd.hpp and intrinsic_fwd.hpp. You get the idea.

HTH, Eric

[Eric Niebler]

Hack to solve the immediate problem

[Eric Niebler]

Sorry, forgot to mention: the above is a description of how to address the larger issue. For the immediate problem, we can hack some forward declarations directly into segmented_iterator_range.hpp, as in the patch I just attached.

Also, my apologies for not catching this issue sooner. I already added a bunch of _fwd.hpp headers to solve many of these problems and thought I had caught them all. Clearly I was wrong. A consistent policy is needed, but I'll leave that for you to decide.

[Joel de Guzman]

Thanks Eric. This will do for now. Hmm, I guess it's too late to merge to release huh?

[Eric Niebler]

I don't think it's too late, and this is a very low risk fix with a potentially large positive impact. As a release manager, you have my permission.

[Joel de Guzman]

Thanks, Eric! Done.

[Kohei Takahashi <flast@…>]

This is already fixed. djowel, please close.