Re: [boost] [xint] Boost.XInt formal review (concrete complaint)

Subject: Re: [boost] [xint] Boost.XInt formal review (concrete complaint)
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-07 09:33:21

On Mon, 07 Mar 2011 09:45:02 +0100
Ivan Le Lann <ivan.lelann_at_[hidden]> wrote:

>>> I don't think that this is enough to prevent surprises. If someone
>>> does
>>>
>>> thread t( f, x );
>>>
>>> where x is an integer, the thread would receive a shared copy of x.
>>> The user would need to explicitly call the copy constructor with a
>>> second argument of true to avoid that.
>> 
>> You'd think so, but so long as that thread class takes the integer
>> parameter as either a constant reference or by value, or is the only
>> one thread accessing it if it's passed by non-constant reference,
>> that's not the case. 
>
> I'm not sure I understand why you say that t does not get a shared
> copy. Anyway what seemed obvious to me with current impl is that block
> below can either leak or double destruct x data. Am I wrong?
>
> void f (integer) {} // by value
> ...
> {
>   integer x = 42;
>   async ( f, x );
>   async ( f, x );
> }

It depends on the implementation of async. If async takes x as a const
reference, then it *would* be shared between them, but presumably they
would finish with it before 'f' exits... otherwise, passing a local to
them is a client-code design bug. If it's a non-const reference, and
both calls make changes to it, that's another client-code bug that the
library can't do much about.

If async passes them by value, then there's no trouble. Unless you
explicitly tell the library to use CoW on external objects, it will
deep-copy them, so each call to async will get its own storage.

So if the client code is written to avoid bugs, the way that it would
have to be with any kind of object, XInt will do the right thing.
-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*