public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-53225-4-gzzLQHkPN0@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-53225-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225 --- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> 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 <cstddef> #include <stdlib.h> #include <assert.h> 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++
next prev parent reply other threads:[~2012-05-04 21:52 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-05-04 3:30 [Bug c++/53225] New: " dimitrisdad at gmail dot com 2012-05-04 3:35 ` [Bug c++/53225] " dimitrisdad at gmail dot com 2012-05-04 3:41 ` pinskia at gcc dot gnu.org 2012-05-04 5:21 ` dimitrisdad at gmail dot com 2012-05-04 8:55 ` redi at gcc dot gnu.org 2012-05-04 9:44 ` redi at gcc dot gnu.org 2012-05-04 18:12 ` dimitrisdad at gmail dot com 2012-05-04 18:32 ` redi at gcc dot gnu.org 2012-05-04 18:57 ` dimitrisdad at gmail dot com 2012-05-04 19:25 ` dimitrisdad at gmail dot com 2012-05-04 19:45 ` redi at gcc dot gnu.org 2012-05-04 19:59 ` dimitrisdad at gmail dot com 2012-05-04 20:02 ` dimitrisdad at gmail dot com 2012-05-04 20:10 ` daniel.kruegler at googlemail dot com 2012-05-04 20:18 ` dimitrisdad at gmail dot com 2012-05-04 20:35 ` redi at gcc dot gnu.org 2012-05-04 20:56 ` dimitrisdad at gmail dot com 2012-05-04 20:59 ` redi at gcc dot gnu.org 2012-05-04 21:07 ` redi at gcc dot gnu.org 2012-05-04 21:16 ` dimitrisdad at gmail dot com 2012-05-04 21:27 ` dimitrisdad at gmail dot com 2012-05-04 21:30 ` redi at gcc dot gnu.org 2012-05-04 21:41 ` dimitrisdad at gmail dot com 2012-05-04 21:52 ` redi at gcc dot gnu.org [this message] 2012-05-04 21:56 ` redi at gcc dot gnu.org 2012-05-04 22:01 ` dimitrisdad at gmail dot com 2012-05-04 22:05 ` daniel.kruegler at googlemail dot com 2012-05-04 22:07 ` pinskia at gcc dot gnu.org 2012-05-04 22:09 ` redi at gcc dot gnu.org 2012-05-04 22:31 ` dimitrisdad at gmail dot com 2012-05-04 22:55 ` dimitrisdad at gmail dot com 2012-05-04 23:21 ` redi at gcc dot gnu.org 2012-05-04 23:37 ` dimitrisdad at gmail dot com 2012-05-04 23:37 ` dimitrisdad at gmail dot com 2012-05-05 0:04 ` pinskia at gcc dot gnu.org 2012-05-05 0:15 ` redi at gcc dot gnu.org 2012-05-05 0:49 ` dimitrisdad at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-53225-4-gzzLQHkPN0@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).