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

On 12/27/2010 2:56 AM, Hartmut Kaiser wrote:
>> 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.

This has recently been a recurring problem. I'm highly considering putting
all of fusion's components in ADL barriers.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net




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