From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22742 invoked by alias); 30 Jul 2008 20:38:35 -0000 Received: (qmail 22733 invoked by uid 22791); 30 Jul 2008 20:38:34 -0000 X-Spam-Check-By: sourceware.org Received: from mailgw10.technion.ac.il (HELO mailgw10.technion.ac.il) (132.68.225.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jul 2008 20:38:15 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIBAJFtkEiERAEcmGdsb2JhbACLH4c3AQEBAQENDxGfBw X-IronPort-AV: E=Sophos;i="4.31,281,1215378000"; d="scan'208";a="121625984" Received: from techunix.technion.ac.il ([132.68.1.28]) by mailgw10.technion.ac.il with ESMTP; 30 Jul 2008 23:38:10 +0300 Received: from [127.0.0.1] (techunix.technion.ac.il [132.68.1.28]) by techunix.technion.ac.il (Postfix) with ESMTP id B97C1149AF; Wed, 30 Jul 2008 23:38:09 +0300 (IDT) (envelope-from mveksler@tx.technion.ac.il) Message-ID: <4890D134.4090209@tx.technion.ac.il> Date: Thu, 31 Jul 2008 04:52:00 -0000 From: Michael Veksler User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: David Carlton Cc: gdb@sources.redhat.com Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <488F4AA7.7060001@gnu.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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-07/txt/msg00341.txt.bz2 David Carlton wrote: > Which language will lead to more people enjoying contributing to GDB? > Which language will lead to more people feeling like they can work at > full productivity while contributing to GDB? How will the choice of > language affect GDB's institutional memory? How will the choice of > language affect whether or not newcomers are likely to join in, > whether or not they're likely to stay involved? > I have never contributed one line of code to GDB, however this could be different. The story: Several years ago I have encountered a crippling bug for AIX+g++ debugging which would make gdb crash on the first breakpoint. It is possible that there is a PR for this, I don't remember. The cause for the crash was that some of the stabs debug info got reordered by AIX's /bin/ld and /bin/as (which seems to be within the spec, by the way). This reordering sometimes confused gdb and an assertion was fired up. After seeing the mess of gdb code in that area I gave up fixing this bug in gdb. What I ended up doing is to hack gcc-3.2 to emit redundant debug information, such that reordering will not make any difference for gdb. Unfortunately, gcc would not accept my 10 lines patch (because the bug was not in gcc) and I had to maintain a private gcc (which I ended up sending to several people who found me through google). My conclusion: If GDB had used c++ std containers it would be much easier for me to *read* the code and then reorganize it. I don't claim that debugging C++ is any easier, but I do claim that understanding code *intent* is easier (as long as the coders follow the prime guideline - do not surprise the reader) I would have written a 1000 lines patch if I could only figure out what gdb was doing in a reasonable amount of time. I *believe* that if that piece of code had used std containers then gdb would see more random contributions than it does today (in that piece of code). This is only my personal belief. I am biased since I have been writing c++ code for the past 11 years (wrote C for 5 years before that). Against c++ I would say that writing good c++ code (without shooting yourself through all your limbs) requires self control and experience. Sometimes it requires deep knowledge of weird corners in the language (which took me years to mostly master). Simply minimize your friction with such corners by e.g. defining templates only in very rare cases when the benefits are huge and several experts are willing to provide nearly 24h/7 support for them (or avoid them altogether). I will never remember the rules for writing a template function which is a friend of a template class - inside the class definition (every compiler has different corner cases and bugs for this kind of stuff), I simply avoid it - not worth the trouble. Michael