From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2821 invoked by alias); 6 Nov 2013 11:31:40 -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 2810 invoked by uid 89); 6 Nov 2013 11:31:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-wg0-f54.google.com Received: from Unknown (HELO mail-wg0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 06 Nov 2013 11:31:10 +0000 Received: by mail-wg0-f54.google.com with SMTP id c11so4679465wgh.21 for ; Wed, 06 Nov 2013 03:31:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.73.40 with SMTP id i8mr20750491wiv.37.1383737461033; Wed, 06 Nov 2013 03:31:01 -0800 (PST) Received: by 10.195.12.114 with HTTP; Wed, 6 Nov 2013 03:31:00 -0800 (PST) In-Reply-To: <527A21DB.301@codesourcery.com> References: <5271CBF9.2070005@redhat.com> <1383236801-13234-1-git-send-email-dmalcolm@redhat.com> <527960A8.7030107@redhat.com> <527A21DB.301@codesourcery.com> Date: Wed, 06 Nov 2013 11:43:00 -0000 Message-ID: Subject: Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3) From: Richard Biener To: Bernd Schmidt Cc: Jeff Law , David Malcolm , GCC Patches , Andrew MacLeod Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00551.txt.bz2 On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt wrote: > On 11/06/2013 10:31 AM, Richard Biener wrote: >> We decided to move to C++. As part of a later discussion we decided >> to go with a single general dynamic-casting style, mimicing the "real" >> C++ variant which is dynamic_cast < ... >. Which resulted in >> is-a.h. >> >> So yes, we've decided to go C++ so we have to live with certain >> uglinesses of that decisions (and maybe over time those uglinesses >> will fade away and we get used to it and like it). >> >> Thus, there isn't another option besides using the is-a.h machinery >> and enabling and using RTTI. Sticking to C for gimple doesn't seem >> to be consistent with the decision to move to C++. >> >> Oh, I'm not saying I'm a big fan of as_a / is_a or C++ in general >> as it plays out right now. But well, we've had the discussion and >> had a decision. > > Maybe we need to revisit it? As one of those who were not in favour of > the C++ move, can I ask you guys to step back for a moment and think > about - what do all of these changes buy us, exactly? Imagine the state > at the end, where everything is converted and supposedly the temporary > ugliness is gone, what have we gained over the code as it is now? as_a gains us less runtime checking and more static type checking which is good. > I still think all this effort is misdirected and distracts us from > making changes that improve gcc for its users. That I agree to. Instead of fixing the less than optimal separation / boundary between frontends and the middle-end, or fixing several other long-standing issues with GCC we spend a lot of time refactoring things to be C++. But that was kind of part of the decision (though I remember that we mainly wanted to convert containters and isolated stuff, not gimple or trees (I bet that'll be next)). Of course I don't see contributors of "changes that improve gcc for its users" now wasting their time with converting code to C++. That conversion may slow down those people, but only so much. It'll get more interesting with branch maintainance ... Richard. > > Bernd >