From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25098 invoked by alias); 4 Aug 2008 09:34:37 -0000 Received: (qmail 24722 invoked by uid 22791); 4 Aug 2008 09:34:21 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Aug 2008 09:33:34 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id D87E020B85 for ; Mon, 4 Aug 2008 11:33:30 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id BE43320AF8 for ; Mon, 4 Aug 2008 11:33:30 +0200 (CEST) From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb@sources.redhat.com Subject: Re: Move GDB to C++ ? Date: Mon, 04 Aug 2008 09:34:00 -0000 User-Agent: KMail/1.9.9 References: <487658F7.1090508@earthlink.net> <200808011606.16574.apoenitz@trolltech.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808041136.12690.apoenitz@trolltech.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00056.txt.bz2 On Friday 01 August 2008 17:18:26 Eli Zaretskii wrote: > > From: =3D?utf-8?q?Andr=3DC3=3DA9_P=3DC3=3DB6nitz?=3D > > Date: Fri, 1 Aug 2008 16:06:14 +0200 > >=20 > > I can think of a few directions that might be interesting: > >=20 > > (1) a working, full featured MI interface, > > (2) integrated scripting, > > (3) performance improvements. > > (4) gdb-as-a-library. > >=20 > > The question whether they are hard "because it's C" is open: > > You will say no, I say yes, simply because high level restructuring > > is more painful in C than in reasonably C++. >=20 > Don't worry about what I'm going to say. Just give specific arguments > why C++ will enable these directions significantly better than C. If > you do that, you might be surprised by what I will have to say. The reasons are the basically the same as the one I gave in other parts of this thread. Assuming a rational approach to the type and way C++ features are used we have: 1. Using C++ reduces source code size typically by a factor of 2 or more _while improving readability_ as the the code that vanishes from the sources is boiler plate code for, say, manipulating containers, or=20 cleaning up within a function. The remaining "essence" is easier to browse, faster to scan by humans and easier to refactor. 2. C++ helps to pick the right containers and algorithms at the beginning, and makes it easier to switch later in case of errors as different types of containers and algorithms often offer similar interfaces - despite of different implementations and performance characteristics. This is in stark contrast with C where container access and manipulation is typically "manually" inlined on the user side (up to the degree where "containers" as such do not even exist but rather are conventions like "start at a pointer, and end at the next embedded end-marker", or "this item, and whatever is linked from its 'next' pointer"). Refactoring such code, say,=20 replacing the container with some other with different performance characteristics, typically involves a complete rewrite of the user code, and is far more error prone as "sticking to the conventions" more often than not cannot be checked by the compiler itself. The ability to refactor easily will certainly help with gdb performance. Also, it helps when creating "higher level functionality", when it is not clear on the outset how a good solution would look like. E.g. MI currently is a mess (sorry for being blut again...). Incomplete,=20 inconsistent, and misleadingly documented. Incidentally, C++ can help to create more uniform internal interfaces as _using_ such is much more common than the "inline-everything-manually-and- micro-optimize-as-you-type-and-only-use-functions-when-really- needed"-style approach of C. n. On top of that: C++ does not hurt. C code can stay (sometimes with minor adjustments) if needed and none of the advantages cited above are wanted. Also, C++ _is_ widely available, and also g++ 2.95.3 would fit the bill for what I think gdb needs. I just notice I wrote something like that already, so maybe I'd better stop. As far as I can tell, all arguments have been on the table for a few times now. The strongest argument against that I saw was Mark's fear that using C++ for future gdb releases might hamper his ability to use a seven year old compiler for non-GNU-base=20 operating systems, and that fear is very likely to be unfounded. Of course I can't tell for sure since he did not point to any specific=20 problem. I doubt there is any for our (my?) envisioned usage pattern. The fear of "inevitable smart pointer invasion" is certainly not=20 realisitic... Regards, Andr=C3=A9 PS: I am also somewhat tired of this discussion now. I suppose I'll=20 try again in a few years...