|
Boost : |
From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-05-18 22:00:19
Eric Niebler <eric_at_[hidden]> writes:
> Tough questions. You've touched on a weakness of proto. I hope to make
> improvements in this area after BoostCon ...
>
>
> Maurizio Vitale wrote:
>> Suppose I needed a new tag for representing some high-level concept that I do not want
>> to express in terms of C++ operators [it could be a get_bit(N) operation that has very
>> different implementation when for my numbers the unserlyining implementation is a
>> builtin type or a GMP big int]
>>
>> Here's my code for adding a binary operator my_plus:
>>
>> struct my_plus {};
>>
>> template<typename Left, typename Right>
>> proto::expr<my_plus, proto::args2<proto::ref_<Left>, proto::ref_<Right> > > const
>> make_my_plus_expr(Left& left, Right& right)
>> {
>> typedef proto::expr<my_plus, proto::args2<proto::ref_<Left>, proto::ref_<Right> > > expr_type;
>> expr_type that={left,right};
>> return proto::generate<typename Left::domain, expr_type>::make (that);
>> }
>>
>> Questions:
>>
>> - is the above the right way, or is there some friendlier interface?
There's another way to achieve the same effect by just declaring a nullary my_plus and then let the
proto machinery do its job by mean of operator()().
In this case the result would be:
(function (terminal my_plus expr0 expr1))
The grammar can take care that only binary applications are allowed [my_plus could even declare its arity so that this
can be done in a generic way].
What are pro/cons of the two solutions?
Compile-time evaluation should be the same (albeit probably more expensive at compile-time).
For evaluation in contexts I think the matching becomes more difficult to express (haven't tired it, maybe it doesn't
even work) in that you need to overload on function_tag and then use boost::{dis,en}able_if to control the
overload set. Run-time cost should be the same.
Eric, are the two approach equivalent? or you see particular advantages for one of them?
Regards,
Maurizio
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk