------- Comment #156 from gdr at cs dot tamu dot edu 2007-05-24 10:29 -------
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"rguenther at suse dot de" <[EMAIL PROTECTED]> writes:
[...]
| > I brought in the union example to point of a fundamental problem with
| > this issue. I have been following the discussion without saying much,
| > until I realized that the interpretation Mark was offering is a
| > redefinition of the C++ object model that conflicts with the current
| > standard text. That was the point of the union example. In the
| > example
| >
| > void f(int* p, double* q) {
| > *p = 42;
| > *q = 3.12;
| > }
| >
| > All we know is that after the store to *p, the object there will have
| > type int (if it did not already have one). Similarly, for the store
| > to *q, the object there will have type double. Can the stores be
| > rearranged? Under the current C++ rules (which were inherited from
| > C90, and not C99) "yes" if we know that the objects are distinct.
| > Can we infer the disjoinctness from the types? "Not always" under
| > current C++ rules for union, and in this specific case, the answer is
| > "no".
|
| Right, current C++ rules forbid exchanging the stores. But I read it
| as it is because the stores may start lifetime of a different
| dynamically typed object on the same memory location which p and q
| may point to.
Which is equivalent to having the union, in all aspects.
Now, if I understand your argument below correctly, you are saying
that even if we fixed the union rules for C++, we may still be facing
the same problem because assignment to POD objects does not just mean
that the object was there before, but that we are actually starting a
new one. Do I understand your argument correctly?
| Whether there is a union "placed" at this memory
| location is irrelevant. I read the standard as if the above is
| equivalent to
|
| *(new (p) int) = 42;
| *(new (q) double) = 3.12;
|
| which as long as we cannot prove that p does not point to the
| same memory location as q means that we cannot reorder the stores.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
