Re: [boost] [boost::proto] bug with large (> 8) values for BOOST_PROTO_MAX_ARITY

From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-05-02 23:16:18

Eric Niebler <eric_at_[hidden]> writes:

> This is only a problem on GCC because of a compiler bug wrt template 
> template parameters. Proto reuses a work-around from the MPL, which is 
> conditioned on an MPL macro called BOOST_MPL_LIMIT_METAFUNCTION_ARITY. 
> If you define this to be at least as large as BOOST_PROTO_MAX_ARITY, the 
> problem goes away.

Mmmh, does the code I sent compile for you when ARITY==8?
It still doesn't for me.
(I get "ambiguous overload of operator OP", which is jargon for "your
 expression doesn't match the grammar")

I've synched up and I see your change in matches.hpp for checking the
proper settings of BOOST_MPL_LIMIT_METAFUNCTION_ARITY.

> Also, in another mail, you say:
>
>> I'm really interested in having patterns with those many arguments, so once
>> the variable controlling the maximum arity and the one controlling the maximum
>> number of subpatterns in a pattern get decoupled I may be fine, but still
>> giving a clear error message would be helpful. 
>
> Depending on what "number of subpatterns in a pattern" means, you may 
> already have what you want. There is a separate macro called 
> BOOST_PROTO_MAX_LOGICAL_ARITY which controls how many parameters 
> proto::or_ and proto::and_ accept. It is independent of 
> BOOST_PROTO_MAX_ARITY. For the time being, whether a pattern such as 
> number<_,_,_,_,_,_,_,_> is accepted is controlled by BOOST_PROTO_MAX_ARITY.

I mean number<_,_,_,_,_,_,_,_>. I'll probably try to reduce the number of arguments
by grouping even more of them in other structs, but for now I haven't come up with
the right ones, which is why I prefer to have them lined up and do the grouping
only once.

Regards,

        Maurizio