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

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-07 08:42:10

From: "Itay Maman" <itay_maman_at_[hidden]>

>
> "David Abrahams" <dave_at_[hidden]> wrote in message
a > news:06fd01c23dd8$63911d00$62f0fc0c_at_boostconsulting.com...
> > From: "Eric Friedman" <ebf_at_[hidden]>
> >
> >
> > >
> > > Additional features of my boost::aligned_storage include:
> > >
> > >  * aligned_storage::swap_as<T> and aligned_storage::assign_as<T>
provide
> > > strong exception-safety guarantee
> >
> > If those things are supposed to have the "obvious" semantics, well,
I'll
> > believe it when I see it.
> >
> > If you don't know something extra about T it isn't in general possible
to
> > produce a strong guarantee swap or assignment.
> >
> > -Dave
> >
>
>
>
> Although swap() cannot uphold the no-throw guarantee, it can be made
> (strongly) exception safe. Here is a snip from one of the previous
versions
> of the variant library, without the alignment handling stuff. (Brad King
> should be credited for a bug fix).

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

1 The lifetime of an object is a runtime property of the object. The
lifetime of an object of type T begins when: --- storage with the
proper alignment and size for type T is obtained, and --- if T is a
class type with a non-trivial constructor (12.1), the constructor call
has completed.  The lifetime of an object of type T ends when: --- if
T is a class type with a non-trivial destructor (12.4), the destructor
call starts, or --- the storage which the object occupies is reused or
released.

2 [Note: the lifetime of an array object or of an object of type (3.9)
starts as soon as storage with proper size and alignment is obtained,
and its lifetime ends when the storage which the array or object
occupies is reused or released. 12.6.2 describes the lifetime of base
and member subobjects. ]

3 The properties ascribed to objects throughout this International
Standard apply for a given object only dur- ing its lifetime. [Note:
in particular, before the lifetime of an object starts and after its
lifetime ends there are significant restrictions on the use of the
object, as described below, in 12.6.2 and in 12.7. Also, the behavior
of an object under construction and destruction might not be the same
as the behavior of an object whose lifetime has started and not
ended. 12.6.2 and 12.7 describe the behavior of objects during the
con- struction and destruction phases. ]

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

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com