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

On 12/23/2010 8:34 PM, Hartmut Kaiser wrote:
> 
>> I have a fairly large program that compiled just fine on boost_trunk
>> version 67416, but is now broken.  I traced to problem to an ambiguous
>> operator overload that occurs when both qi.hpp and fusion/tuple.hpp are
>> included.
>>
>> The following code does not compile as of today, but should compile on
>> version 67416.
>>
>> #include <boost/fusion/tuple.hpp> //including this file caused ambiguity
>> errors #include <boost/spirit/include/qi.hpp> #include <string>
>>
>> int main()
>> {
>>   static const boost::spirit::qi::rule<std::string::const_iterator> a;
>>   static const boost::spirit::qi::rule<std::string::const_iterator> b;
>>   boost::spirit::qi::rule<std::string::const_iterator> rule = a > b; }
>>
> 
> Ohh, that looks serious! The ambiguity is caused by a proto/fusion overlap. 
> A qi::rule is both, a proto expression and a fusion sequence (as all proto
> expressions are proto sequences now). 
> 
> Proto's overload for operator>() is a valid choice for this, as is fusions
> operator>().
> 
> I'm cc'ing Eric and Christopher, perhaps they have an idea how to proceed.

I suggest defining a Fusion trait, is_less_then_comparable, and define
it for the built-in Fusion sequences (tuple, vector, etc.). That can be
used to SFINAE out Fusion's operator<, which should not be picked up for
Proto expressions. Ditto for the other operations on Fusion sequences.

I have no better ideas at the moment.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com