Subject: Re: [proto] Problems with unary function node
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-10-29 05:19:38
On 10/29/2011 06:37 AM, Eric Niebler wrote:
> It could be that I'm stupid, or that I'm tired, or that your explanation
> is insufficient ... but I don't get it.
My explanation is just a few bits from what kind of thing we do, sorry
it wasn't helpful. It may help to say that it's not the actual
expression that I'm categorizing, but its children.
A generator like that would be problematic for example
typedef typename proto::result_of::child_c<Expr&, 0>::type child0;
typename result_of<proto::_default(child0)>::type result_type;
result_type operator()( Expr& expr
, typename impl::state_param
, typename impl::data_param
In the case of operator()(), child0 would be the expression<
terminal<...> >, which is also incomplete.
Now that's not a very good thing for a generator to do, but some
generators require in our case to do some manipulations with somewhat
complex transforms on the children.
Regardless, it seems to me that
> you still want your expressions to have a unary function operator, but
> that you don't want to compute its return type eagerly.
Ideally yes, but it's pretty simple, so I specialized the generator for
that case and avoided introspecting the type.
> And as you said,
> that's just not possible in today's language. My patch solves the
> problem only for those people who want to turn off unary function
> completely. Ditto for assign.
Ok, I think it's a good thing. Do you have an idea of how much
compile-time it costs to do so?
> What should you do? Avoid calling those generic categorization
> metafunctions in your generator. The generator has to assume the type it
> computes is incomplete.
That's quite a severe restriction.
It's only necessary for operator()() and operator=(expression const&),
so I'd rather I don't have to apply this restriction to the other node
I think this should be documented.
Proto list run by eric at boostpro.com