Christopher Schmidt wrote:
Eric Niebler schrieb:
Hi Fusion gurus. I'm chasing an elusive bug that the following Proto test has exposed:
http://beta.boost.org/development/tests/trunk/developer/output/RW_WinXP_VC-b... <snip>
Does anyone from Fusion team want to give this a crack? I'll be happy to help.
Changeset 57337, in particular the change in boost/fusion/view/reverse_view/reverse_view.hpp, causes the trouble. I only tested this changeset with my default toolchain (gcc 4.4) as I did not consider any of my changes to be breaking. I am awfully sorry.
No worries.
The change in reverse_view.hpp causes fusion::reverse_view to always be a bidirectional access sequence, even if the underlying sequence is a random access one. This is correct behaviour according to the documentation.
What is the motivation for this change? It seems to me that a reversed random-access range can and should be random-access as well.
The problem in proto is probably caused by a bug in the VC9/VC10 compiler. The non-random-access implementation of fusion::detail::fold wrongly causes the compiler to instantiate nested template parameters of the functor.
I attached a minimal sample which reproduces this problem.
You should file a bug with Microsoft and attach the preprocessed source code. I can do this if you don't know how.
Interestingly, the random-access fold implementation works fine in your particular usecase, whereas my sample reproduces the problem for forward and random access sequences. I also attached a temporary workaround-patch for proto.
Proto's fold transform should work with any forward fusion sequence, so I'm afraid I cannot apply your patch because it may break third-party code.
Unfortunately I have no idea of how to "fix" fusion in the first place.
Is reverting the change to reverse_view and option? -- Eric Niebler BoostPro Computing http://www.boostpro.com