From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11635 invoked by alias); 23 May 2007 23:58:40 -0000 Received: (qmail 11594 invoked by alias); 23 May 2007 23:58:30 -0000 Date: Wed, 23 May 2007 23:58:00 -0000 Message-ID: <20070523235830.11592.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "gdr at cs dot tamu dot edu" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg02088.txt.bz2 ------- Comment #151 from gdr at cs dot tamu dot edu 2007-05-24 00:58 ------- 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" writes: [...] | > Gaby's model says that we know less about dynamic types than we | > presently think we do, because there might be a union out there | > somewhere. (Fortunately, as Joseph points out, C99 has already answered | > this question. Surely we can agree that making C99 and C++ different in | > this respect is a bad idea.) | | I don't think dragging in unions helps us here ;) Maybe Gaby can clarify | if and how unions relate here, but I didn't percieve any previous comment | as making implicit unions relevant here apart from what GCC and | apperantly C99 agree to. I believe we all agree that placement new changes the dynamic type. 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". I never said I liked that model. I was merely pointing out that people where on the slope of redefining the object model. I spent the afternoon trying to see how C++ can move forward. The "effective types" of C99 has its own sets of incompleteness and inconsistency problems that Nick MacLaren has brought to my attention since I raised the issue on the C++ -core reflector. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286