Boost logo

Boost :

From: Thomas Wenisch (twenisch_at_[hidden])
Date: 2003-02-25 13:58:51

Hi all,

On Tue, 25 Feb 2003, Fernando Cacciola wrote:

> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:018a01c2dccf$ab5c5050$1d00a8c0_at_pdimov2...
> >
> > template<class T> void * operator new(size_t n, optional<T> & t);
> >
> Anyway, there are still problems with this: operator new is called _before_
> the T is constructed, so there won't be a way, AFAICT, to properly set the
> initialized flag ('cause if T ctor throws, placement new won't be aware of
> it)

Additionally, I think writing into the object in operator new before the
object is constructed leads to undefined behavior, or, at least, not the
behavior you want. I tried something similar once, where operator new
filled in a data member of the object being created, and the constructors
for the object left that data member unitialized. However, it turned out
that Intel C++ 7.0 zeroed out the entire object via memset() before
invoking my constructor, wiping out the data stored by operator new. I
could find nothing in the standard that prohibited icc from doing this.

The fix is to move the data member either before or after the object, and
have operator new allocate extra memory. Perhaps you could put the
initialized flag before the optional<>, and have operator new initialize
this bool to false. If optional<>'s constructor knows that there is a
bool located immediately before the optional in memory, it can calculate
the address of it and access it, even though it lives outside the actual
optional<> object.

I don't understand all the issues here, so I am not sure if this helps at
all. Also, there are alignment issues that need to be dealt with, to
assure that both the bool and the optional<T> are properly aligned, but
I'm sure these can be handled.

-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University

Boost list run by bdawes at, gregod at, cpdaniel at, john at