I am facing these below issues when I upgrade from boost_1_73 and c++14 to boost_1_77 and c++17. What will be the problem?
**Error 1:**
include/boost/utility/result_of.hpp:218:8: error: 'GB* (boost::intrusive_ptr::*)() const noexcept' is not a class, struct, or union type
**Error 2:**
include/boost/phoenix/core/detail/function_eval.hpp:119:21: error: no type named 'type' in 'struct boost::result_of<GB* (boost::intrusive_ptr::* const(boost::intrusive_ptr&))() const noexcept>'
Here is a snip of code causing the issue but can't share more code sorry.
run = qi::lit("g_d")[qi::_val = phoenix::new_<GB>()] > qi::lit("{") >
-(*iPtr)[phoenix::bind(&ECProperty::addToList,
phoenix::bind(&GBPtr::get, qi::_val), qi::_1)] >
+(&!qi::lit("}") > widthAndHeight(qi::_val)) > qi::lit("}");
Like I said, there's not enough information. Let me just use the crystal ball and assume types:
Now like I said,
GBPtrcannot bestd::shared_ptr,boost::shared_ptror evenboost::scoped_ptrbecause they lack implicit conversion (for good reason). So, we have to assume some kind of bespoke variation, let's call itDumbPointer:Okay, now we can look at the grammar. Let's assume
iPtris really a "lazy rule" of some kind, so*iPtris not a parser expression using Kleene-star, but really just derefences the pointer:Next, let's assume
withAndHeightis a parameterized rule (why? oh well apparently there was some reason):So we can make the grammar complete and self-contained:
Note a few very minor simplifications.
Now, the compiler error reads:
It is clear that Phoenix's result_of doesn't accept a raw pointer-to-member-function there. No doubt, the
noexceptthrows it off (noexceptdidn't exist back in the day). So, let's help the compiler usingstd::mem_fn:Now it compiles. Good, let's imagine some useful definition of
withAndHeight:Now we can test:
Which prints Live On Compiler Explorer:
Buttt... This Is C++17, So...
Perhaps you could simplify. An idea is to extract the phoenix actors:
Still the same output: https://compiler-explorer.com/z/ec331KW4W
However, that is a bit like turd polish. Let's embrace c++17 with polymorphic lambdas and CTAD:
Or even better, without polymorphic lambdas:
Now we can simply write:
See it Live Again
Other Notes
Why have the inherited attribute? It complicates things:
That's strictly more consistent. See it Live Again
In fact, why not just do it without any semantic action:
Now you can simply:
And still have the exact same output: https://compiler-explorer.com/z/3PqYMEqqP. Full listing for reference: