Comment 4 for bug 1368478

> 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.