From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31742 invoked by alias); 29 Jul 2008 19:32:42 -0000 Received: (qmail 31734 invoked by uid 22791); 29 Jul 2008 19:32:41 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jul 2008 19:32:20 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id B4AB4390157 for ; Tue, 29 Jul 2008 16:13:25 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m6TJSZqK4223134 for ; Tue, 29 Jul 2008 16:28:35 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6TJSTsM019797 for ; Tue, 29 Jul 2008 16:28:29 -0300 Received: from [9.18.238.102] ([9.18.238.102]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6TJST9R019792 for ; Tue, 29 Jul 2008 16:28:29 -0300 Subject: Re: Move GDB to C++ ? From: Thiago Jung Bauermann To: gdb@sources.redhat.com In-Reply-To: References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <488F4AA7.7060001@gnu.org> <488F5CAA.8050902@gnu.org> Content-Type: text/plain Date: Tue, 29 Jul 2008 19:35:00 -0000 Message-Id: <1217359709.5842.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 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/msg00307.txt.bz2 Just a clarification which I forgot to make... On Tue, 2008-07-29 at 15:58 -0300, Thiago Jung Bauermann wrote: > 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. Which is not to say that I am against discussions about redesigning GDB. If such discussions occur in the mailing list I will follow the threads with great interest and provide input if I can. I just think that they are not a prerequisite for this C++ discussion. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center