Boost logo

Proto :

Subject: Re: [proto] [Spirit-devel] [Spirit Development] Bug in today's boost_trunk -- ambiguous operator >
From: Eric Niebler (eric_at_[hidden])
Date: 2010-12-23 20:41:25

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

Proto list run by eric at