From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25663 invoked by alias); 7 May 2004 23:42:08 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 25649 invoked from network); 7 May 2004 23:42:07 -0000 Received: from unknown (HELO smtp-relay-7.sea.adobe.com) (192.150.22.7) by sourceware.org with SMTP; 7 May 2004 23:42:07 -0000 Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i47Ng4SP025772; Fri, 7 May 2004 16:42:05 -0700 (PDT) Received: from iplan-mn (iplan-mn.corp.adobe.com [130.248.25.5]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i47Nfx3k008904; Fri, 7 May 2004 16:41:59 -0700 (PDT) Received: from mn-eljayet.adobe.com ([130.248.178.4]) by iplan-mn.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HXD00DO2B5W4E@iplan-mn.corp.adobe.com>; Fri, 07 May 2004 18:41:57 -0500 (CDT) Date: Fri, 07 May 2004 23:42:00 -0000 From: Eljay Love-Jensen Subject: Re: sizeof with virtual inheritance In-reply-to: X-Sender: eljay@iplan-mn.corp.adobe.com To: Adrian Sandor , gcc-help@gcc.gnu.org Message-id: <6.0.3.0.2.20040507183402.020bfe58@iplan-mn.corp.adobe.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <6.0.3.0.2.20040427070648.01f97650@iplan-mn.corp.adobe.com> <6.0.3.0.2.20040507151558.020039d8@iplan-mn.corp.adobe.com> X-SW-Source: 2004-05/txt/msg00086.txt.bz2 Hi Adrian, >How can I see the layout like that? I just enhanced your example. $ cat Adrian.cpp #include using namespace std; struct c1{char x; void p1() const;}; struct c2:public c1{void p2() const;}; struct c3:public c1{void p3() const;}; struct c4:virtual public c1{void p4() const;}; struct c5:virtual public c1{void p5() const;}; struct c6:public c2, public c3{void p6() const;}; struct c7:public c4, public c5{void p7() const;}; #define P(x) \ void c##x::p##x() const \ { \ cerr << "c" #x ":" << (void*)this << endl; \ } P(1) P(2) P(3) P(4) P(5) P(6) P(7) #define S(x) cout<<"c"#x<<": "<And what is the actual use of that "pointer for the multiple inheritance overhead"? Multiple inheritance incurs a potential extra level of indirection. >What does it point to and when and how is it used? I believe it points to a class layout map. When a multiple-inherited object is passed to a routine -- especially one that takes one of it's parent class types -- it has to take into account that the memory layout may be something unexpected. This descrambling of multiple-inheritance is different from that of the virtual function table. But both have the similarity of adding overhead. >Is it possible to disable it, especially that it's at the end of the layout? Yes, you can disable it using the GCC __attribute__((packed)) decoration. But I strongly suggest you don't do that, since (likely) you'll make the class unusable in an array, non-inheritable, and not able to be used as a member variable in another class. And the __attribute__ extension is a GCC-ism. HTH, --Eljay