From: Maurizio Vitale (mav_at_[hidden])
Date: 2008-03-27 21:26:58
Eric Niebler <eric_at_[hidden]> writes:
>> Another issue I remember was related to BOOST_PROTO_MAX_ARITY. It is
>> (was?) controlling both the maximum arity of boost expressions _and_
>> the arity of templates in grammars. Eric promised to decouple the two
>> uses, but in my quick look at the docs I couldn't find out whether
>> it has happened or not. I believe this change should really go in.
>
> Refresh my memory ... what do you mean by, "the arity of templates in
> grammars"? Are you referring to the number of template parameters that
> proto::or_ and proto::and_ accept? If so, then yes, you can control this
> separately with BOOST_PROTO_MAX_LOGICAL_ARITY (not documented, darn!).
> If you mean the max arity of expressions like
>
> terminal< MyGinormousTemplate<_,_,_,_,_,_,_,_> >
>
> then no, this cannot be controlled independently. Do you want that?
It is the latter. It bit me with two consecutive strikes:
- I had no idea there was a limit, as it is not (I believe) mentioned
anywhere
- I didn't guess that the the controller was BOOST_PROTO_MAX_ARITY,
as this is documented as controlling the maximum arity of proto
expressions.
I'd prefer to have a separate macro for each separate control
(especially if there's a compile time gain in increasing only one). And
since you have BOOST_PROTO_MAX_LOGICAL_ARITY I think it makes sense for
orthogonality. What about BOOST_PROTO_MAX_TEMPLATE_ARITY.
But at minimum the effects of BOOST_PROTO_MAX_ARITY should be fully
documented. Seeing it mentioned might raise a red flag for people -
if I remember correctly the error messages from GCC for this case
weren't particularly enlightning.
[I think you ruled out an explicit tests on compilation speed grounds]
>> The last design issue I had was about whether expressions should allow
>> to store terminals by value. This might be different with the work on
>> integrating fusion, I don't know.
>> In my application (fixed-point arithmetic) I had cases where my object
>> could have been stored by value and taking the space of an int (or less)
>> and I would have liked to be able to do so. I admit mine was probably a
>> very special case, where the quality of the assembler code generated was
>> of upmost importance (must rival hand-written code).
>> I don't remember the details of the conversation with Eric on this, but
>> I think his conclusion was that allowing the user to specify the storage
>> policy would have made compilation in the typical case slower.
>> Still...
>
> There is a way to get what you want today, using a custom generator. If
> you want, I can show you how. If it doesn't meet your needs, I'm open to
> considering alternatives.
Not now, but in the summer I plan to get back to my fixed-point library.
If I'll still have problems after studying the new implementation and
documentation I'll ask. Thanks,
Maurizio