What writes cause a trivially-copyable object to become alive?

43 views
Skip to first unread message

Johannes Schaub

unread,
Jul 24, 2012, 5:22:14 PM7/24/12
to std-dis...@isocpp.org
I take it that the intent of  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1116 is that the following creates an "int" object in the storage pointed to by "p"

    void *m = malloc(sizeof *p);
    int *p = (int*)m;
    *p = 0;

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;

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? 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;

Lawrence Crowl

unread,
Jul 24, 2012, 6:15:28 PM7/24/12
to std-dis...@isocpp.org
On 7/24/12, Johannes Schaub <schaub....@googlemail.com> wrote:
> I take it that the intent of
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1116
> is that the following creates an "int" object in the storage
> pointed to by "p"
>
> void *m = malloc(sizeof *p);
> int *p = (int*)m;
> *p = 0;

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
Reply all
Reply to author
Forward
0 new messages