From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25797 invoked by alias); 6 Nov 2013 20:50:36 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25786 invoked by uid 89); 6 Nov 2013 20:50:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,RDNS_NONE autolearn=no version=3.3.2 X-HELO: smtp.mozilla.org Received: from Unknown (HELO smtp.mozilla.org) (63.245.216.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Nov 2013 20:50:35 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [64.213.68.131]) (Authenticated sender: tsaunders@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 77F1CF27BE for ; Wed, 6 Nov 2013 12:50:27 -0800 (PST) Date: Wed, 06 Nov 2013 20:57:00 -0000 From: Trevor Saunders To: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3) Message-ID: <20131106205025.GA23061@tsaunders-iceball.corp.tor1.mozilla.com> References: <5271CBF9.2070005@redhat.com> <1383236801-13234-1-git-send-email-dmalcolm@redhat.com> <527960A8.7030107@redhat.com> <1383688624.5282.111.camel@surprise> <52796D38.2010602@redhat.com> <527AA8BF.8000301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527AA8BF.8000301@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00647.txt.bz2 On Wed, Nov 06, 2013 at 01:38:23PM -0700, Jeff Law wrote: > On 11/05/13 16:23, Ian Lance Taylor wrote: > >On Tue, Nov 5, 2013 at 2:12 PM, Jeff Law wrote: > >> > >>I can't speak for Andrew, but my experience with this kind of object type > >>casting in a large C++ project is that it's a red flag for a design problem. > > > >I'm going to chime in to say that I think it's a pretty typical way to > >represent a compiler IR in C++. There is a base type that a lot of > >code uses, but there is also a real type, and the way to get to that > >real type is to use a cast. We could do it all with virtual > >functions, but those carry a different cost. In effect, using virtual > >functions increases the size of the code field from 16 bits to 64 > >bits. It adds up. > > > >Also this seems to be a pretty direct version of the data structures > >we already have. > Certainly and to some degree these casts in one form or another are > a necessity. My concern is we use them as a crutch (as I've seen in > other projects) and we end up not getting the level of compile time > static type checking that we want. So, thinking about this more the is_a / as_a is more or less just a translation of the "union casting" we're already doing, which means while we may not be getting everything we would like we're atleast getting as good or better than what we have modulo stylistic tastes. > If the bulk are temporary in nature and we as a project agree to > look at the refactoring necessary to minimize the is-a/as-a uses to > a few low level idioms, then I'll hesitatingly go along. If that's > the choice we make, then folks should know I'll probably look at > each is-a/as-a in patches I review and ask for a justification for > their use. I think that's a reasonable thing to do fwiw. Trev > > > jeff