Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2011-03-07 07:44:03

On 07/03/11 11:48, Christopher Jefferson wrote:
>
> On 7 Mar 2011, at 06:34, Joel Falcou wrote:
>
>> On 07/03/11 03:25, Peter Dimov wrote:
>>> I probably should note that expression templates require CoW, as far as I can see; if you return an expression from a*b instead of computing the product, the expression needs to keep a and b alive. Having it store copies would defeat the purpose. Storing references wouldn't work well in generic code such as a forwarding function. Even something as simple as auto x = f() + y; would be a subtle bug.
>> Well , ET based code usually keep references to large terminals. the 'auto'/ET interaction is known and is likely to never occurs.
>> And if needed, well, that's what proto::deep_copy is for.
>
> So users of a expression-template based xint would need to know about proto::deep_copy?
>
> Also, I would expect these problems to become more serious in C++0x code, because users will probably write expressions like:
>
> auto i = x + y;
>
> Which would be fine for built-in types, and introduce bugs if x or y was an xint::integer, using proto.
>

auto i = x + y; does what it need to do, build an expression type. The 
only problem will arise if x and y has a shorter life span than i, which 
is usually not the case in random code.

When does it happen ? When someone do something like:

auto f( X const& x) -> decltype(x+x*declval<X>())
{
   auto that = x + x*X();
   return that;
}

In this case, problem arise as X() wont be there out of f().

Note however than:

auto f( X const& x) -> decltype(x+x*x)
{
   auto that = x + x*x;
   return that;
}

do work as intended by passing along the locally constructed AST to 
build a larger one at calling site.

Now, my guess is that const ref lifespan propagation still apply in 0x, 
so doing somethign along:

auto f( X const& x) -> decltype(x+x*declval<X const>())
{
   X const local;
   auto that = x + x*local;
   return that;
}

will surely works (more or less, untested code). And if not, there is 
the only case where some deep_copy *may* be needed.

And all in all, in these particular case, i wonder if a c++0x enabled 
proto wont just be able to have rvalue-ref expression nodes that let it 
fly properly.

Applying 0x logic to 03 based code is not very correct. I'll keep this 
issue in mind when we'll look at porting proto in 0x, and in 0x, proto 
will surely be a totally different beast inside.