RE: [boost] Re: Mini-review request: aligned_storage.hpp

From: Eric Friedman (ebf_at_[hidden])
Date: 2002-08-07 15:15:13

David Abrahams wrote:
> That's a lot of code to read through, but if it's doing what I think
it's doing,
> it's undefined behavior.
> 
> Is the trick to move the bits for an existing object into a buffer so
we can
> tentatively construct a new object in that memory, and later move the
old bits
> back temporarily to destroy the old object?
> 
> The standard does not give license to do that: only one object may
have a given
> address at a time. See 3.8, and particularly paragraph 4:
> 
> 3.8 Object Lifetime
> 
[snip]
> 
> 4 A program may end the lifetime of any object by reusing the storage
which the
> object occupies or by explicitly calling the destructor for an object
of a class
> type with a non-trivial destructor. For an object of a class type with
a non-trivial
> destructor, the program is not required to call the destructor
explicitly before
> the storage which the object occupies is reused or released; however,
if there is
> no explicit call to the destructor or if a delete-expression (5.3.5)
is not used to
> release the storage, the destructor shall not be implicitly called and
any program
> that depends on the side effects produced by the destructor has
undefined behavior.

Yep, that's the trick. Well that's not too good news for Boost.Variant,
now is it?

Three questions come to my mind:

 * Are there any implementations that do not behave as desired under
this undefined
   behavior? (Or more fundamentally, what is the reason for the
standard's behavior
   on this issue?)

 * Is it a major obstacle that Boost.Variant will not offer
exception-safe assign
   or swap unless externally wrapped with the pimpl idiom? Should
boost::fast_variant
   and boost::safe_variant be introduced to encapsulate yet allow choice
in this issue?

 * Any ideas out there as to how to make variant::operator= and
variant::swap "as safe
   as possible," yet still efficient, even if we can't guarantee strong
exception-safety?

Thanks,
Eric Friedman