Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2007-04-26 12:57:40


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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk