From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32472 invoked by alias); 29 Jul 2008 19:05:52 -0000 Received: (qmail 32407 invoked by uid 22791); 29 Jul 2008 19:05:26 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jul 2008 19:05:06 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1KNuVK-000443-KQ for gdb@sources.redhat.com; Tue, 29 Jul 2008 19:05:02 +0000 Received: from 32.104.18.240 ([32.104.18.240]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Jul 2008 19:05:02 +0000 Received: from bauerman by 32.104.18.240 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Jul 2008 19:05:02 +0000 To: gdb@sources.redhat.com From: Thiago Jung Bauermann Subject: Re: Move GDB to C++ ? Date: Tue, 29 Jul 2008 19:06:00 -0000 Message-ID: References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <488F4AA7.7060001@gnu.org> <488F5CAA.8050902@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 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/msg00304.txt.bz2 Andrew Cagney wrote: > The question I'm asking here is are we focusing on C++ as a solution, > and mistakenly trying to rely on its features as a solution, when we > should instead be first focusing on the design, what ever the > implementation language? > If, in attempting to make these changes we find that the C > implementation truly cumbersome then we've a compelling story for > language change. IMHO one of the reasons that this thread keeps coming up is that current GDB design already begs for implementation in an OO language (witness the home-brewed implementation of exceptions). So if one agrees with that (I do), then it is not out of place to discuss a move to an OO language. > This is assuming that the intent here is find ways > to allow greater architectural reform in GDB (and a language change is > just an aid to that goal). You seem to at least be agreeing with this? I'd be surprised if anyone said no to that. :-) But there's at least one other goal: lower the barrier to entry for would-be GDB hackers (or one which are at the beginning of their journey and still didn't grasp the whole picture of the GDB internals). It has been said already that needing to learn the GDB in-house equivalent of estabished OO features and/or idioms (like cleanups, GDB exceptions and others) is a significant obstacle to new contributors. I agree with that. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center