[boost] Re: basic guarantees in variant

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-09 15:42:14

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

> --- David Abrahams <dave_at_[hidden]> wrote:
> [...]
>> > 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.
>> 
>>
>> 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.
>
> Look again at the standard.
>
> "A program may end the lifetime of any object by reusing the storage
> which the object occupies"

Do you really think I missed that sentence?  You can prove almost
anything you want to about C++ by picking a single sentence out of
the standard on its own.

> It doesn't define the process of how exactly the storage gets
> reused, does it?  "reusing storage" what does it mean?
>
> When you do an assignment in variant it is the process
> of reusing the storage that is not defined in the standard.

You have to read and think about the whole clause to understand the
problems.  That one sentence doesn't stand by itself.

Once you reuse the storage for the object, its lifetime has ended.
The first problem is that clients of variant should have the right to
depend on side-effects of that object's destruction (anything else
makes variant a very strange beast to use, indeed), but if they do,
it's undefined behavior (see the last sentence of the clause).

The second problem, even if the program doesn't depend on the
side-effects of the object's destructor, is: copying the saved bits
back to that location do not constitute beginning the lifetime of a
new object if it has a non-trivial constructor (see the beginning of
the clause -- you have to call a constructor do that).  It should be
obvious that you can't call the destructor of an object whose lifetime
has never begun.  I'll leave you to find that in the standard if it
isn't obvious to you.  The destructor call you use after copying away
the bits of the newly-constructed object resulting from assignment
causes undefined behavior.

That is about as clear as it is possible to make this issue.  If you
have any argument with my analysis, please go to comp.std.c++ or some
other forum and get the opinions of other standards experts before
bringing them to me because I am not going to try to explain it any
more and nothing you can say without the strength of a standards
expert's authority to back it up, at this point, will impress me.

> FYI I don't really care about your comments other than technical.
> You can relax a bit.

If you would like me to be relaxed, you'll stop making arrogant
pronouncements, treat your fellow Boosters as though they may have
done a little thinking about the issues and might even know something
you don't, especially lay off remarks like "stop kidding yourself",
and approach the issue with a genuine spirit of inquiry rather than as
though you already know all the answers.  There's more to having a
productive technical discussion than just making "technical comments."

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