Maurizio Vitale wrote:
Eric Niebler <eric@boost-consulting.com> 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.
Totally agreed.
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::___.
<snip>
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