This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strenghten assumption about dynamic type changes (placement new)


> 
> As discussen during the Cauldron keeping some builtin doesn't help because
> you are not forced to access the newly created object via the pointer returned
> by the placement new.  That is,
> 
>   template <T>
>  struct Storage {
>      char x[sizeof(T)];
>     Storage() { new (x) T; }
>     T& get() { return reinterpret_cast <T&> (x); }
> };

This indeed looks like sensible use of placement new...
> 
> is valid (and used in this way in Boost - with a type different from 'char'
> to force bigger alignment).

This testcase with char replaced to long or other POD type is still fine for my analysis.
I would like to assume that once a polymorphic type is built at a given location, it can
not be changed to other, that is:

  template <T>
 struct Storage {
     Q x;
    Storage() { new (x) T; }
    T& get() { return reinterpret_cast <T&> (x); }
};

Where both T and Q are polymorphic types. I think essentially aliasing rules
disallows this (for Q and T being different types at least, not sure if one
inherits other) because Q gets constructed and thus accessed. But it is sliperly
indeed, as whole concept of placement new.

I believe easiest way to go forward is to extend polymorphic_call_context to
also hold speculative information about outer type.  In the cases I can detect
a dynamic type but can not prove it did not changed, I still can use the
speculative path.  This is not perfect, but will improve code quality.

I am still hoping we can get sensible rules for placement new :)

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]