From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29664 invoked by alias); 1 Jul 2015 14:59:42 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29655 invoked by uid 89); 1 Jul 2015 14:59:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 01 Jul 2015 14:59:40 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A0CF82B649A; Wed, 1 Jul 2015 14:59:39 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t61Exbh6000647; Wed, 1 Jul 2015 10:59:38 -0400 Message-ID: <55940059.30603@redhat.com> Date: Wed, 01 Jul 2015 14:59:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jan Kratochvil CC: Yao Qi , gdb-patches@sourceware.org, Phil Muldoon Subject: Re: [patchv2] compile: Fix crash on cv-qualified self-reference References: <20150418172843.GA17777@host1.jankratochvil.net> <20150516132555.GB17266@host1.jankratochvil.net> <86lhf0p1hf.fsf@gmail.com> <20150701132406.GA13975@host1.jankratochvil.net> <5593F10D.4020903@redhat.com> <20150701141003.GA19545@host1.jankratochvil.net> In-Reply-To: <20150701141003.GA19545@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00048.txt.bz2 On 07/01/2015 03:10 PM, Jan Kratochvil wrote: > On Wed, 01 Jul 2015 15:54:21 +0200, Pedro Alves wrote: >> > On 07/01/2015 02:24 PM, Jan Kratochvil wrote: >> > >>> > > I can change it that way but when you ask "isn't cleaner" then no, I think >>> > > your hack is even a bit more ugly than my ugly hack. >>> > > >>> > > There should be two virtual methods, one pure for 'switch (TYPE_CODE (type))' >>> > > and the other one checking TYPE_INSTANCE_FLAG* in superclass overriden only by >>> > > TYPE_CODE_STRUCT and TYPE_CODE_UNION (there would be no TYPE_CODE_*, though). >> > >> > What would be the method name? > class Type { > protected: > virtual GccType convert_unqualified ()=0; > public: > explicit virtual GccType operator() { > if (instance_flags==0) return convert_unqualified(); > ... > } > }; > > class StructType:public Type { > protected: > virtual GccType convert_unqualified () { assert(0) } > public: > explicit virtual GccType operator() override { ... } > }; > > class IntegerType:public Type { > protected: > virtual GccType convert_unqualified () { assert(instance_flags==0); ... } > }; > Well, I'd say that having the core GDB Type be aware of GccType directly would be a misdesign, not a feature. > Althoughth qualifications could be possibly also subclassed which would look > differently again. Yes, the "possibly" here is the crux. Subclassing isn't always the best choice. There are trade offs. >> > There's nothing preventing adding a new type_FOO function that takes a type >> > pointer as parameter and hides the TYPE_CODE checks inside. From the >> > caller's perspective, it'll be the same. Once we get to C++ and if we >> > consider objectifying type, then converting that function to a method will >> > be trivial. > Do you mean simulation of C++ virtual method table by a struct of pointers, > like in other cases in GDB? > No. I meant a straightforward conversion of your C++ methods to C functions implemented in terms of switch/TYPE_CODE. IIUC, in your C++ class tree you'd do: gcctype = (GccType) type; So a trivial 1-1 conversion or your code would be: // Type::convert_unqualified () // StructType::convert_unqualified () gcc_type type_convert_unqualified (struct type *) { switch (TYPE_CODE (type)) { case TYPE_CODE_STRUCT: assert(0); default: ... } } // Type::GccType operator() gcc_type type_as_gcc_type (struct type *type) { if (TYPE_INSTANCE_FLAGS (instance_flags) == 0) return type_convert_unqualified (type); ... } Then the caller in question would use: gcctype = type_as_gcc_type (type); I'm very much looking forward to C++ as well, but switch/case vs virtual methods here is really more about syntax sugar than design. You can easily end up with a broken class inheritance tree just as well. There's a lot more to it beyond design than language. Thanks, Pedro Alves