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
- I didn't guess that the the controller was BOOST_PROTO_MAX_ARITY,
as this is documented as controlling the maximum arity of proto
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.
> 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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk