From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23101 invoked by alias); 4 May 2012 21:52:08 -0000 Received: (qmail 23090 invoked by uid 22791); 4 May 2012 21:52:07 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 May 2012 21:51:54 +0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class Date: Fri, 04 May 2012 21:52:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-05/txt/msg00510.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225 --- Comment #22 from Jonathan Wakely 2012-05-04 21:51:39 UTC --- (In reply to comment #19) > Johnathan, const static members are compile time beasts. There are almost > macros like #define, but not quite as the compiler will give them storage if > you take their address. Please don't try to C++ to me. How do you explain that "int_type" is int in A::f() and not short? > I don't think it is a good idea to add another > paradigm into this. Ignore the static const, explain the typedef. > Nor does your example explain how the field moved and was > correctly assigned in the code I gave above with method() - if I were to accept > your example as valid, then that code would not work - but it does, there is > is. You can compile it, and get the memory dumps yourself in gdb. Can you > speak to that example with method()? That would be very useful. It didn't "move" > (gdb) p &(b_pt->count) > $1 = (uint *) 0x804a00c > (gdb) x/10 b_pt > 0x804a008: 5 0 0 0 > 0x804a018: 0 0 0 0 > 0x804a028: 0 135129 > (gdb) p b_pt > $2 = (B *) 0x804a008 At 0x804a008 there is a B object. Inside that B object is a C object, also at address 0x804a008, and an A object at address 0x804a00c. Think of the B as a little box with two object in it. Inside the A at 0x804a00c is an integer called "count" and that is also at address 0x804a00c. The memory looks like this: 0x804a008 0x804a00c B----------------------------- C--------------A-------------- y--------------count---------- Inside operator new you get a piece of memory, big enough for a B, then you cast that memory to A* and dereference it to access A::count. Because you cast the memory to A* the compiler access "count" at that address (see the diagram, the "count" member is at offset zero into an A. here's your invalid example adjusted to use a normal member instead of operator new, it fails in the same way: #include #include #include typedef unsigned int uint; class C{ // just here to be faithful to the original code int y; }; class A{ public: typedef A this_type; static void* create(size_t enfacia_size, uint count){ size_t total_size = enfacia_size + sizeof(int) * count; // the 'tail' ; this_type *new_pt = (this_type *)calloc(total_size, 1); new_pt->count = count; return new_pt; } uint count; }; class B : public C, public A{ public: int i; }; int main(){ B *b_pt = (B*) B::create(sizeof(B), 5); assert(b_pt->count == 5); } There's nothing special about operator new, you just don't understand C++