From: Eric Niebler (eric_at_[hidden])
Date: 2007-04-26 17:44:45
Maurizio Vitale wrote:
> Eric Niebler <eric_at_[hidden]> writes:
>> 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?
> If it has the same weight in terms of compilation time, of course.
> I thought that maybe there was a cheaper way to detect the error, like a specialization
> with some large number of default arguments that kicks in only above BOOST_PROTO_MAX_ARITY
> and is not even defined, so that you get an error.
I doubt it would be less expensive to merely detect the error than to
handle it correctly.
A thought. BOOST_PROTO_MAX_ARITY is primarily for controlling how many
children a node in an expression tree is allowed to have. There's no
good reason to tie it to the max arity of templates that
proto::matches<> can handle. There should be a separate constant for
that, and perhaps it could default to something higher than 5.
> If it is not possible/desirable then the limit should be spelled out in the documentation,
> both as a general rule and in the section on grammars, as it might not be obvious to the
> newcomer that BOOST_PROTO_MAX_ARITY applies to patterns as well.
>>> 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.
> I know it works, but I don't think is in the documentation.
Yep, the docs are currently lacking.
>>> 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::___.
> What about _n or _s? [the first would stay for N copies and
> the second for the plural of _] or _*_ if one wants to get creative w/
> operators. The main question for me is whether it is hard to code and
> whether it would impact the long term maintainability of the
> library. If it is easy we can found a short name for it (actually I'm
> not sure that _s is valid, although I believe it is).
> Also, imo, to be useful shouldn't stay for "all the arguments", but
> rather for "all the arguments that haven't been mentioned", so
> std::basic_string<char,_s> would also be valid (and mean
> std::basic_string<char,_,_> ). No idea whether this is doable.
Doable, but not trivially. In all likelihood it'll make proto::matches<>
compile slower in the general case. My gut feeling is that this feature
isn't worth the trouble.
-- 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