pto_var / ParseExp.cpp fails with boost 1.56.0

Sorry, I forgot to mention I didn't test this change with older boost versions.
Although I'm pretty sure it's backwards-compatible I can't easily test this over here at the moment.

Thank you for your patch.
Boost 1.56 has Spirit version 2.5.3. This Spirit version was introduced with Boost 1.50.
In the release notes of Boost 1.56 I don't see changes to spirit.
On WIndows it compiles fine with Boost 1.56, no errors.

So I assume there is something other involved.
Can you give a link about the changed interface?
Which compiler did you use?

> On WIndows it compiles fine with Boost 1.56, no errors.

Now that is interesting, I didn't expect that. On the other hand the windows side of boost is probably quite different..

I just noticed that I updated gcc to 4.9.1 and boost to 1.56.0 at around the same time, so I'm not sure which
of the errors are triggered by which update.

The first part of the patch, i.e. fixing result::type, is probably not a subject of debate
even if it seems to work with (at the moment) most setups.

Now, here's one of the error messages concerning the second problem:

<<<
/usr/src/hugin-2013.0.0/src/tools/ParseExp.cpp:185:20: required from here
/usr/include/boost/phoenix/core/detail/preprocessed/function_eval_10.hpp:185:51: error: invalid initialization of non-const reference of type 'boost::phoenix::
detail::function_eval::result<boost::phoenix::detail::function_eval(const boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::
argsns_::term<Parser::lazy_if_>, 0l>&, const boost::phoenix::actor<boost::spirit::argument<0> >&, const boost::phoenix::actor<boost::spirit::argument<1> >&, co
nst boost::phoenix::actor<boost::spirit::argument<2> >&, const boost::phoenix::vector2<boost::phoenix::vector4<const boost::phoenix::actor<boost::proto::exprns
_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::ar
gsns_::term<boost::spirit::attribute<0> >, 0l>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::prot
o::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<Parser::lazy_if_>, 0l>, boost::phoenix::ac
tor<boost::spirit::argument<0> >, boost::phoenix::actor<boost::spirit::argument<1> >, boost::phoenix::actor<boost::spirit::argument<2> > >, 4l> > >, 2l> >*, bo
ost::fusion::vector3<double, double, double>&, boost::spirit::context<boost::fusion::cons<double&, boost::fusion::nil_>, boost::fusion::vector0<> >&, bool&>&,
const boost::phoenix::default_actions&>&)>::type {aka double&}' from an rvalue of type 'double'
                 return boost::phoenix::eval(f, ctx)(help_rvalue_deduction(boost::phoenix::eval(a0, ctx)) , help_rvalue_deduction(boost::phoenix::eval(a1, ctx)
) , help_rvalue_deduction(boost::phoenix::eval(a2, ctx)));
>>>

I'm not _actually_ sure this isn't a bug in either Spirit or Phoenix instead of wrong usage in hugin,
but as boost 1.56.0 is released it's no harm to work around this problem in hugin.

Your patch breaks compilation with older boost versions.
I committed a strongly modified version.
I tested with
* Windows (MSVC) + Boost 1.56
* Linux + Boost 1.48 + gcc 4.7.2
* Linux + Boost 1.55 + gcc 4.8.2
and all 3 compile fine.

It does not contain the second part. This does modify the arguments which can have unwanted side-effects to the parser.

Ah, so it _was_ a change in Phoenix. I wonder why they didn't add a note on that to the 1.56-Release page...
I'll test your changes later today.

Will this be part of the 2014 release?