[boost] Re: basic guarantees in variant

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-09 11:52:38

"E. Gladyshev" <egladysh_at_[hidden]> writes:

> --- David Abrahams <dave_at_[hidden]> wrote:
>> Yes, but not for anything else.  This is exactly the memcpy trick that
>> Eric was referring to earlier.  The fact that you spelled it
>> "variant_copy" and not "memcpy" doesn't change anything; it has the
>> same semantics.  I don't know why we have to keep going over the same
>> ground over and over again.  All of this is in the discussion
>> archives.  If people would just go back and do some review we could
>> avoid lots of wasted bandwidth and, I dare say, aggravation.
>
>
> variant_copy() is completely defined.  Eric's concerns about
> memcpy was that is undefinded.

No it wasn't.  It's that the copy-away/copy-back behavior you've
implemented is undefined.

> Stop kidding yourself, variant_copy is much more predicable
> than new T() that variant is using to provide basic guarantess.
> Theretically, if a copy constructor crashes the memory
> heap could already be corrupted.
> The stack solution is much more safer in this respect
> and it provides strong guarantess.

Sorry...

> [...] 
>
>> No, you can't.
>
> Yes, you can.

No, you can't.

I am really losing patience with this silliness.  Are you so certain
you're right that you'r unwilling to even look in the standard or the
mail archives when you're told that this ground has already been
covered?  

http://aspn.activestate.com/ASPN/Mail/Message/1311813

Should be easy enough for you, now.  Please stop wasting everyone's
time, especially mine.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com