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

Joel de Guzman schrieb:
> 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.

I agree. This breaks a lot of code but in the long term we will avoid
lots of trouble.
Unfortunately 1.46 is closed for major changes on the 10th of January.
That does not leave much time for implementing, testing and documenting
such a change. Fusion itself internally relies on ADL - we'd need to
audit every line of Fusion in order to get it working again.

Is a preliminary revert an option? If we reverted [67342] and [67352],
it would work again?

-Christopher


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