|
|
Proto : |
Subject: Re: [proto] Using make_expr with as_child or as_expr
From: Eric Niebler (eric_at_[hidden])
Date: 2011-05-01 05:41:24
On 4/18/2011 8:44 PM, Mathias Gaunard wrote:
> make_expr is a fairly "funny" function, in that it decides whether the
> children should be taken by value or reference depending on whether
> they're wrapped in boost::(c)ref or not.
Yes, it's a peculiar interface, but I couldn't think of anything better.
> In some cases, I really want to write something like
>
> proto::make_expr(
> proto::as_child(a0),
> proto::as_child(a1)
> )
>
> but that kind of thing doesn't work, due to the funny way make_expr works.
It doesn't work? I *think* that would have the effect of building a new
node that would store children by value, making a0 and a1 expressions
(if they weren't already) by storing the terminal by reference. Is that
not what you were expecting? What are you trying to do?
> I guess the perfect solution would be for make_expr to detect whether
> its argument is an rvalue and take it by value in that case, and take by
> reference otherwise.
> But that could be tricky for a C++03 compiler.
Yes, that's the problem.
> I suggest that in the time being, variants of proto::make_expr be added:
>
> proto::make_expr_expr(a0, a1) would take terminals by value and the rest
> by reference
>
> proto::make_expr_child(a0, a1) would take terminals by reference and the
> rest by value
What is the design rationale for these? In what common situations would
these be more convenient than proto::make_expr?
> Names, of course, could be improved.
Yeah, those names don't convey any useful information to me.
> Maybe there is already some functions I missed that do what I want?
No, proto::make_expr is the one to use. It's interface is complicated by
the fact that it allows its arguments to be Proto expressions or not
(converting non-expressions into terminals), and wrapped in
boost::reference_wrapper or not (which controls how they're stored). It
feels a bit like this one function is trying to do too much, but I'm not
convinced that adding more functions that do roughly the same thing
would be an improvement.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Proto list run by eric at boostpro.com