hugin-devs team mailing list archive

[v4hn <1368478@xxxxxxxxxxxxxxxxxx>]

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

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1368478

Title:
  pto_var / ParseExp.cpp fails with boost 1.56.0

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Heya,

  I just spend two hours reading through boost's documentation on result_of
  and Spirit and a lot of cryptic error messages. So I thought I should probably send
  my results upstream so others don't have to do that again.

  With boost 1.56.0 hugin produces a number of errors in src/tools/ParseExp.cpp.
  The first one (with all the junk removed) is:

  <<<
  /usr/include/boost/utility/result_of.hpp:189:8: error: wrong number of template arguments (1, should be 3)
   struct result_of_nested_result : F::template result<FArgs>
          ^
  /usr/src/hugin-2013.0.0/src/tools/ParseExp.cpp:80:12: error: provided for 'template<class X, class Y, class Z> struct Parser::lazy_if_::result'
       struct result { typedef Y type; };
              ^
  >>>

  Actually I'm not sure why this part ever compiled successfully, but I
  suppose boost just got a bit more strict now...

  The second problem seems to be a change in Spirit that makes it
  neccessary to rewrite the lazy_functions a bit.

  I attached a patch for all problems I encountered when building hugin (2013.0.0) with boost 1.56.0.
  I also just checked and your recent release candidate does not include changes in this part of the code,
  so I'm pretty sure the bug exists also with the 2014rc

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1368478/+subscriptions