Boost logo

Boost :

Subject: Re: [boost] [proto] small breaking change
From: Eric Niebler (eric_at_[hidden])
Date: 2010-06-14 17:38:44

On 6/14/2010 4:09 PM, joel falcou wrote:
> Eric Niebler wrote:
>> I was mistaken about falling foul of RVO. Here is what is happening. You
>> have two domains in play, both with different generators. You compose
>> some expressions in different domains, A and B. Proto decides the
>> resulting expression R should be in domain B. Proto prefers things to be
>> nice and uniform, so before making A a child of R, it puts it also into
>> B's domain by applying B's generator. That causes the extra copy you're
>> seeing. If A and B had had the same generator, no extra invocation of
>> the generator would be performed.
>> Why does Proto put expression A into B's domain? Good question. It just
>> seemed like the right thing to do when I wrote the code. Right now, that
>> looks like a dubious decision. Lemme think on it for a bit
> Don't know if it'll help you but, back in the day where subdomain didn't
> exist, NT2 used a
> as(a,b) function to make a comaptible with b. It was like :
> template<class Y,class C,class X> static inline
> typename boost::proto::result_of::
> make_expr < tags::as_
> , containers::domain<typename Y::nt2_category_tag>
> , containers::expr<X,C> const&
> >::type const
> as( containers::expr<X,C> const& xpr, Y const& )
> {
> return boost::proto::
> make_expr < tags::as_
> , containers::domain<typename Y::nt2_category_tag>
> > ( boost::cref(xpr) );
> }
> and it worked without any copy as a was stored as a reference in a
> special node.

This jogged my memory a bit. My reasoning at the time was that someone
might want to use as_expr to explicitly put a proto expression into a
particular domain -- something like your as() function. But in
hindsight, a separate function for that might have been better. as_expr
should just do one thing: adapt non-proto types to proto. If something
is already a proto type, just leave it alone. If the user wants to apply
some other domain's generator to it, she can just do that.

I've made the change on trunk. This could potentially be a breaking
change. For instance, it slightly changes the behavior of your as()
function; it no longer will invoke Y's generator before making X a child
of the new node. I don't think it makes a difference, but we'll see who

Eric Niebler
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at