Re: [C++ patch] Set attributes for C++ runtime library calls

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Thu, Aug 22, 2013 at 8:51 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> I think we must distinguish what is "wrong" according to the standards
>> we are implementing from what is "wrong" from a QoI point of view.
>
> Not if they match, we don't.

In abstract possibly; but your previous assertion needs refinement to
be as categorical as you implied.

>
>> My reasoning (for C++98, but the same is true for C++11) is based
>> on 3.8/1:
>>   […]
>>   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.
>>
>> Doing a placement-new on the storage occupied by 'a' is reusing
>> its storage, therefore ending its lifetime.
>
> The problem is that reused is not well defined,

I am not quite so sure.  But even so, in light of this, I don't think
you original assertion is definitive.

> so, we are into the weeds right there.
>
> int i, j;
>
> int *ip = &i;
>
> i = 1;
> j = 2;
> *ip = j;
> ++i;
> ++j;
>
> here, we sees the storage being reused in the *ip = j;

Really?

> statement, or, is it merely changing the value?

That is an assignment to an existing int storage.

> And what if we do a memcpy (ip, &j, sizeof (int));

Well, the case of 'memcpy' isn't defined by the standard and is
precisely the subject of a issue identified by the C++ SG12
that will be discussed at the Chicago meeting.

>  Is that reused, or merely changing the value.

The current proposal is that it constructs an int value, therefore
is moral equivalent of copy-constructor call.

> I think the most logical line of reasoning is that when the requirements of [basic.lval] are met, the, this is a change of value of an object, not a modification to it's lifetime.

Why?


>  So, in the case quoted, since the type of the accesses are both int, we don't reuse the storage, since the requirements of [basic.lval] are met.

Consider:

    struct S {
        S(int);
        ~S();
        // …
    };

    int main() {
        S s(8);

         new (&s) S(9); // #1
    }

Is #1 a reuse of storage to create a new object or assignment?

>  Indeed, the programmer expects that they can access i after *ip = j; and that the _value_ that object, while changed from the original 1, will be 2 just after the *ip = j; statement.
>
> Since we know that i must be 3 at the end, we then know what the wording, reused, must mean, cause other meanings that could possibly make it work for you in the case you are considering, would destroy this property of pointers, and everyone knows the semantics of pointers, they are undisputed.  Or put another way, you cannot misread reused in this way.

And why do you assert that I misread 'reused' in this way?

-- Gaby