From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20096 invoked by alias); 11 Apr 2012 16:35:03 -0000 Received: (qmail 19590 invoked by uid 22791); 11 Apr 2012 16:34:59 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-lpp01m010-f47.google.com (HELO mail-lpp01m010-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Apr 2012 16:34:46 +0000 Received: by lagw12 with SMTP id w12so873377lag.20 for ; Wed, 11 Apr 2012 09:34:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=8BC00Di31uLnVUGQMXP1Av022G2bKxDaTAZRCwQLr2s=; b=WyXfq/f/Us01Cyn1ic2giik6Ie74RkP26jGejbyUOY8K1tvU/aCbQQZAPY12gW/UZw x/i8GRKC3JK0ke3zOvcjhlAr6phbEG8M5g/Pc5VRt7A5r0azvES1FuAuY1M1NMQlGZTA RrivkaVB8lxzxhxcdVG/scGwu274rsTe5hiWm1tDY3yl5edffCHh7N2IhkmSgnexni0R 9wNv6GffAfO3srlGVNLZBlbT8gVHwHf0zc/O2ryxenXaE7MeFLjKbdlBTY1pJxZrrMjg 74iW8ufMOVeAMpUNN4Je5htXBKUu/jEV6/BdfYMSh2HVhfitucwK1SVJwZdHnaLOINmJ 10hg== Received: by 10.112.30.170 with SMTP id t10mr3206292lbh.10.1334162084957; Wed, 11 Apr 2012 09:34:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.30.170 with SMTP id t10mr3206279lbh.10.1334162084849; Wed, 11 Apr 2012 09:34:44 -0700 (PDT) Received: by 10.152.4.233 with HTTP; Wed, 11 Apr 2012 09:34:44 -0700 (PDT) In-Reply-To: References: <4F7B356E.9080003@google.com> <4F7C35A3.3080207@codesourcery.com> <20120410084614.GJ6148@sunsite.ms.mff.cuni.cz> <4F845C2E.9000001@google.com> Date: Wed, 11 Apr 2012 16:35:00 -0000 Message-ID: Subject: Re: Switching to C++ by default in 4.8 From: Xinliang David Li To: Richard Guenther Cc: Diego Novillo , Gabriel Dos Reis , David Edelsohn , Michael Matz , Jakub Jelinek , Bernd Schmidt , gcc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnqwzHxQ7Jq3Kv/qA0jIPciEiHtOjrQpGpOWBb0xUzz/IeJ8zIkaJ6YvM1kHxDtfeodmNshb/4tpYiWlBTe+zMZHHrfbbwN8EQXNbAgYAvldgjjTh10LXV2jUh4FTPzjA1SXfhy X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00425.txt.bz2 On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther wrote: > On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo wrot= e: >> On 4/10/12 12:05 PM, Gabriel Dos Reis wrote: >>> >>> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn >>> =A0wrote: >>> >>>> Also, it will be more convenient to make this change incrementally, >>>> but the GCC community probably will not see much benefit until the >>>> transition is complete. =A0That also means developers asserting benefi= ts >>>> need to be realistic and separate their end vision from what actually >>>> can be achieved in the short and medium term. >>> >>> >>> Fully agreed. >> >> >> Indeed. =A0My personal take on this is that it is going to be a gradual = (for >> some glacially slow) change. =A0I think that debating these points in the >> abstract gains us very little. >> >> Instead, each patch and/or API re-design should be discussed individuall= y. >> =A0Patches will have specific metrics that can be collected. =A0API chan= ges will >> be more of a bike shed, but it will at least lead to more concrete >> discussions. >> >> The end goal for me is simple: modernize the code base to make it more >> attractive to future developers. =A0There is some balancing act to be do= ne, in >> that we should cater to the existing developers as well. =A0But it is ea= sier >> for us, we already know the code and can influence the transition. > > I think it's important to let the C folks slowly accomodate with C++, thus > do not jump-start with even possibly questionable API changes. =A0There > are a _lot_ of "obvious" candidates that are even well contained (thus no > fear of a can of partial-C++ transitions) like the various containers we = use > and APIs which are not in wide-spread use, like the cgraph API (which Hon= za > is about to turn upside down). I think this is a good plan to move forward -- I also agree cgraph is a good candidate. Other candidates include optimization driver/pass manager, IR text dumper, persistent IR dumper/reader etc. > > I also agree that > > =A0exp->as_component_ref().get_field() > > is exceptionally bad. =A0Both for the compile-time of the above expressio= ns > (three function calls that all are need to be inlined?!) I find this less convincing -- the compile time cost should be very small -- and it may also allow more compile time saving: X* derived =3D p->asX(); // runtime assertion done once. derived->do_x_1 (); derived->do_x_2 (); .... As compared with a fat interface case: G* generic =3D p; DO_X_1 (generic); // runtime assertion needed DO_X_2 (generic); // runtime assertion needed ... > and readability. This is again very subjective -- and the style can be hidden under a macro. The benefit of using C++ API is not for the style change, but for proper interface partition. > And I've spent quite some time with various C++ codebases. =A0None was > as ugly as the above (and yes, I consider the LLVM C++ style exceptionally > ugly as well). well, many people will probably disagree here. > > So, please no, do not even try to start the flamewar on C++-ifying trees > or gimple. =A0Not in the next three years at least. > > Propose a nice and usable C++ _plugin_ API that encapsulates trees and > GIMPLE. =A0_Then_ we can talk. I think keeping the core APIs in C is fine even though there are more work to make the current C APIs more user friendly. It might be a good idea to move the core APIs into a separate directory. thanks, David > > Thanks, > Richard. > >> >> Diego.