I suppose that is the intent.
The proposed resolution seems incomplete to me. For trivial types
with no trapping representations, it seems to me that the lifetime
begins with the allocation, not the initial copy. I think the issue
with assignment is that it can both destroy an existing object and
construct a new object in its place.
> When is the object considered to be destroyed (out of timetime)?
> I suppose that the following destroys the int object and creates a
> "float" object
>
> float *x = (float*)m;
> *x = 1.0f;
Agreed.
> What happens when we write using an alias-compatible lvalue?
>
> volatile float *xv = x;
> *xv = 1.0f;
>
> Does this destroy the previous float object and create a
> volatile float object?
I don't think so; it just qualifies the pointer.
> Assume the above write using the volatile lvalue. Then the question
> comes down to whether the following has undefined behavior:
>
> // access of a volatile object using a non-volatile lvalue?
> float xval = *x;
The object is not volatile, but it does have two 'names' for it,
one volatile and one not.
--
Lawrence Crowl