Maurizio Vitale wrote:
- now in reality my number has 6 template arguments. 6 is larger than 5, and with this I've given out what happened, at least to Eric. For others, 5 is the default maximum number of arguments in proto expressions.
So far, so good. The problem is that my grammar had a pattern terminal<number<_,_,_,_,_,_> >. I don't know if it is possible to make proto complain hard and loud about building a pattern (or other expressions) with more arguments than the maximum allowed by configuration, but in my case the pattern was not matching causing my expressions to be invalid.
I don't think there is anything I can do. To detect a template with a too-high arity, I'd need specializations with at least that arity. And if I have an arity-6 specialization, why not make it do the right thing instead of reporting an error? There needs to be a cut-off somewhere, beyond which things will break mysteriously. I don't know if template varargs will improve this situation, but I hope so. (I'd need a template-template vararg.)
And I think that 6 is a better default value for the number of allowed arguments. Just kidding, as long as defining it before including proto headers is officially blessed and documented, I'm ok.
It is. #define BOOST_PROTO_MAX_ARITY 6 should do the trick.
Another nice thing to have, although I would only put it in if very easy to code: especially in presence of default parameters it might be nice to have a pattern matching "the rest of the argument list". Something like a proto::___.
Well, double-underscores are off-limits to user code, according to the standard. But maybe you'd like something like: std::basic_string< vararg<_> > to be the equivalent of std::basic_string< _, _, _ > It doesn't seem like a big win to me, and it wouldn't solve the template arity problem you ran into. -- Eric Niebler Boost Consulting www.boost-consulting.com