Re: [boost] [proto] RValue reference support?

Subject: Re: [boost] [proto] RValue reference support?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-08-11 16:08:25

On Thu, Aug 11, 2011 at 11:11 AM, Eric Niebler <eric_at_[hidden]> wrote:

> On 8/11/2011 10:50 AM, John Maddock wrote:
> >>> But I'm figuring that the occurrence of temporaries on the RHS of an
> >>> expression, while not out of the question, is rare enough not to be too
> >>> concerned about.
> >>
> >> You can use Proto to eliminate the need for temporaries without rvalue
> >> reference support. What you describe above is a textbook application of
> >> expression templates. If it will save you 1 dynamic allocation every now
> >> and then, it's probably worth considering.
> >>
> >> Can you explain again why rvalue references are important for you? I'm
> >> not following.
> >
> > OK, lets say we have an expression:
> >
> > a = x * y + w * z;
> >
> > The order of evaluation might be:
> >
> > *assign x to a.
> > * multiply a by y
> > * create one temporary as a copy of w
> > * multiple temp by z
> > * add temp to a
>
> This part I don't understand, and it's probably because I don't know the
> particulars of the bigint domain. But I know if these things were
> vectors, it would go something like this:
>
> * walk the expression x*y + w*z (at runtime) and calculate the size of
> the resulting vector
> * allocate space for the result vector
> * walk the expression x*y + w*z and evaluate it (also at runtime),
> filling in the result vector directly (no temporaries).
> * swap the result vector with a's
>
> I'm ignorant of how bigint arithmetic works, but I wonder if a similar
> scheme might work here.
>

Maybe, but generally I think this is only really efficient if each component
of the output depends on a small (constant) number of the components of the
input and a small (constant) number of operations.  If there ends up being a
lot of redundant calculations among the various components of the output,
then computing the output fully lazily component-by-component is likely
suboptimal.  E.g., I would think * being a convolution operator would
qualify.

- Jeff