From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10386 invoked by alias); 11 Apr 2012 16:47:09 -0000 Received: (qmail 10336 invoked by uid 22791); 11 Apr 2012 16:47:06 -0000 X-SWARE-Spam-Status: No, hits=-5.0 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,SARE_LWSHORTT,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:46:52 +0000 Received: by lagw12 with SMTP id w12so883881lag.20 for ; Wed, 11 Apr 2012 09:46:50 -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=Usjir7Oswd0n59w+yNk2FmLAnsOPzP/5WDIfTz+aY0s=; b=dd4mvySR7q2uUIw/VEG6XYZR4t89G/cSvfbuD86YvGE0DJUErCfEQdL+169yJOzhQA fj92/FSh2nBYCeJ9oLtxUfkx/hFhEFUjt8qgqWzAfi3Ixyxs5qMWAJ+I9nYmoGtgVtyD MCncQ8YPFSZPV3BX+98n7cLyk2/srpuAO17G6Rjt7DsSleVqqUDzpuXMKoNQvsW1K9uc JRoE8B2hhQuWwYdlf/6LOoVPwarpe03g50evRbEGwM7Yj3MxTT4thXXlu22uU2VecB4G cphD0R6tgfdfOYTrSUUaHTU+fZrzrJyA4jYvsdTQZMofu/Axyt0xEkIJ8GG6iQe0czo3 798g== Received: by 10.112.11.6 with SMTP id m6mr3245752lbb.24.1334162810761; Wed, 11 Apr 2012 09:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.11.6 with SMTP id m6mr3245729lbb.24.1334162810576; Wed, 11 Apr 2012 09:46:50 -0700 (PDT) Received: by 10.152.4.233 with HTTP; Wed, 11 Apr 2012 09:46:50 -0700 (PDT) In-Reply-To: References: <4F7B356E.9080003@google.com> <4F7C35A3.3080207@codesourcery.com> <20120410084614.GJ6148@sunsite.ms.mff.cuni.cz> <20120410163905.GK6148@sunsite.ms.mff.cuni.cz> Date: Wed, 11 Apr 2012 16:47:00 -0000 Message-ID: Subject: Re: Switching to C++ by default in 4.8 From: Xinliang David Li To: Richard Guenther Cc: Lawrence Crowl , Jakub Jelinek , Bernd Schmidt , Gabriel Dos Reis , David Edelsohn , Diego Novillo , gcc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnV/Bx6dVzUn1dl7wsE5/CQwouFA9LgUJ9d3XT7o5VZn1m7c7uY9ctpssr8xcf6wSN7qGz2er5fuRTnp7NNQS9tvhzNAW6OZMCMXjOqVmhcHBZhvBAW57L1I9w8UPOkVw/YkhKv 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/msg00429.txt.bz2 On Wed, Apr 11, 2012 at 2:43 AM, Richard Guenther wrote: > On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl wrote: >> On 4/10/12, Jakub Jelinek wrote: >>> That when stepping through code in the debugger you keep >>> enterring/exiting these one liner inlines, most of them really >>> should be at least by default considered just as normal statements >>> (e.g. glibc heavily uses artificial attribute for those, still >>> gdb doesn't hide those by default). >> >> You do want to step into those inline functions, except when you do. >> In the short term, we can make the debugger behave as though they did >> not exist. =A0In the longer term, we really want debugging tools that >> help C++ programmers. =A0One way to get there is to use C++ ourselves. > > Fix the debugger first please. > >>> > The above is just quickly cooked up examples. A carefully >>> > designed C++ based API can be self documenting and make the >>> > client code very readable. It is hard to believe that there is >>> > no room for improvement in GCC. >>> >>> Do you have examples? =A0E.g. I haven't touched gold, because, >>> while it is a new C++ codebase, looks completely unreadable to >>> me, similarly libdw C++ stuff. =A0A carefully designed C based API >>> can be self documenting and make the code very readable as well, >>> often more so. >> >> If you just look at any decently sized code base, it'll look pretty >> much unreadable. =A0The question is how quickly can someone who learns >> the base vocabulary can produce reasonable modifications. >> >> There are many places where C++ can help substantially. =A0For example: >> >> () The C++ postfix member function call syntax means that following >> a chain of attributes is a linear read of the expression. =A0With C >> function call syntax, you need to read the expression inside out. > > It's a matter of what you are used to (consider LISP). > >> () C++ has both overloaded functions and member functions, so you can >> use the same verb to talk about several different kinds of objects. >> With C function names, we have to invent a new function name for >> each type. =A0Such names are longer and burden both the author and >> the reader of the code. > > Agreed. =A0Function overloading is one of the nice things that does not > automatically make the code-base look "partial C++". =A0Likewise > operator overloading can make things like > > =A0 =A0 =A0 =A0 =A0 =A0bit_offset =3D double_int_add (bit_offset, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 tree_to_double_int > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 (DECL_FIELD_BIT_OFFSET (field))); > > be just > > =A0 =A0 =A0 =A0 =A0 bit_offset =3D bit_offset + DECL_FIELD_BIT_OFFSET (fi= eld); > > it still looks like C but with some C++ "magic". > Function overloading is both bless and curse. It makes code look better, but may reduce debuggability. >> () Standard C++ idioms enable mashing program components with ease. >> The C++ standard library is based on mixing and matching algorithms >> and data structures, via the common idiom of iterators. > > Sort-of agreed. =A0Though iterator-style (and more so functor style) was = never > one of my favorite. > >> () The overloadable operator new means that memory can be >> _implicitly_ allocated in the right place. > > Implicit allocation is bad. =A0In a compiler you want to _see_ where you > spend memory. overload operator new per class allows memory management easier -- many different allocation policies (e.g pool based) can be easily implemented. > >> () Constructors and destructors reduce the number of places in the >> code where you need to do explicit memory management. Without garbage >> collection, leaks are less frequent. =A0With garbage collection, you >> have much less active garbage, and can run longer between collection >> runs. =A0Indeed, a conservative collector would be sufficient. > > Time will tell. > >> () Constructors and destructors also neatly handle actions that >> must occur in pairs. =A0The classic example is mutex lock and unlock. >> Within GCC, timevar operations need to happen in pairs. > > Agreed. > >> () Class hierarchies (even without virtual functions) can directly >> represent type relationships, which means that a debugger dump of >> a C++ type has little unnecessary information, as opposed to the >> present union of structs approach with GCC trees. > > In GCC trees only the "base" is a union, and it is so as implementation > detail. =A0That gdb does not grok a 'tree' well is because gdb is stupid. > All the information is there. > >> () Class hierarchies also mean that programmers can distinguish >> in the pointer types that a function needs a decl parameter, >> without having to say 'all trees' versus 'a very specific tree'. >> The static type checking avoids run-time bugs. > > True. =A0In a very limited set of cases. =A0C++ is not powerful enough > to express pointer-to-everything-that-would-be-considered-a-gimple-val. > Maybe C++ is not the right choice after all? =A0(I suppose C++ concepts > would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ... > (though is_gimple_val is not be a static property). > >> I have written compilers in both C and C++. =A0I much prefer the >> latter. > > Did you ever try to convert an existing large C codebase to C++? > I would not expect a very good result and rather start from scratch. > So I don't see that we ever arrive (or want to arrive) at a pure C++-style > GCC. =A0Instead I expect we end up (and desire to end up) with GCC > compiled with a C++ compiler that uses C++ features to make the > existing style more readable and maintainable. I like your proposal (from my reading) about keeping core APIs in C, while the rest can be migrated (gradually). thanks, David > > Richard. > >> -- >> Lawrence Crowl