Re: [Spirit Development] Bug in today's boost_trunk -- ambiguous operator >

> The example I gave before now works, but I am still having problems with
> ambiguous operator overloading.
> I think it is because in this example I am using a rule with a parameter.
> The solution is probably very similar to the original problem.
> 
> Thanks
> --Robert Nelson
> 
> #include <boost/spirit/include/qi.hpp>
> #include <boost/fusion/tuple.hpp>
> 
> int main()
> {
>   using namespace boost::spirit::qi;
>   int vars;
>   const rule<std::string::const_iterator,int(const int&)> r;
>   rule<std::string::const_iterator,int()> r2 =
> r(boost::phoenix::ref(vars)) > eps;
> }

Yep, this one fails for a similar reason as the first issue. The
spirit::terminal_ex<> (the type of the r(ref(vars)) expression) takes a
fusion::vector<> as one of its template arguments, which causes fusion to be
the associated namespace for spirit in the context of resolving the
operator>(). In this case there is nothing we (as in the Spirit authors)
could do to circumvent the problem.

Seems we're back to square one, where Fusion and Proto need to be changed to
avoid this kind of ambiguities. I still believe that's the right thing to
do, as the issues are caused by (potential) ambiguities introduced by making
proto expressions to be fusion sequences in the first place.

Regards Hartmut
---------------
http://boost-spirit.com




------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl