On Thu, Aug 22, 2013 at 8:51 PM, Mike Stump <mikest...@comcast.net> wrote:
> On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis <g...@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
