From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4966 invoked by alias); 29 Jul 2008 18:09:07 -0000 Received: (qmail 4949 invoked by uid 22791); 29 Jul 2008 18:09:06 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jul 2008 18:08:48 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6TI8khC017799; Tue, 29 Jul 2008 14:08:46 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6TI8kTE008477; Tue, 29 Jul 2008 14:08:46 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6TI8hfE016743; Tue, 29 Jul 2008 14:08:46 -0400 Message-ID: <488F5CAA.8050902@gnu.org> Date: Tue, 29 Jul 2008 19:05:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Vladimir Prus 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=ISO-8859-1; 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/msg00303.txt.bz2 Vladimir Prus wrote: > Andrew Cagney wrote: > > >> Instead of changing GDB to C++ and hoping the change will magically >> transform GDB's code base into a clean ideal design; should we instead >> be focused on trying to address what I suspect is the underlying >> motivation here - a desire to clean up and re-structure GDB's code base >> so that it more clearly corresponds to a more modern Object Oriented design? >> > > I think that trying to use better design without support of a language for which > such design is a native one, would be considerably harder. GNOME is a perfect > example -- in attempt to use OOP in C, they have this GObject thing which is an > approximation of real classes, only harder to use. Ah, and there's even separate > tool, called GOP, that takes class definition in some meta-language and produces > .h and .c file. So, there's fairly complicate non-standard solution for > an already-solved problem. > 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? > Let's use one example in GDB -- values. Presently, struct value has a > field lval_type, and in a number of places, a switch over lval_type is > made. This switch-over-type is a typical red-flag in OOP programs; in case > of GDB this makes it hard to understand what is exact behaviour of > lval_register, for example. CodeSourcery's implementation of register browing > required extending struct value, so that fetching a value goes via special > remote protocol packet. This ended up been not exactly nice. If struct value > was a base class with a defined interface, and each kind of value (rvalue, lvalue, > register, etc) were a derived class, then the internal logic of GDB would be > more clear, and adding new kinds of values would be much simpler. > For instance, an alternative value relationship we've seen proposed: value has-a type has-a location location has-a 1:N piece piece is-a memory piece is-a register piece is-a constant piece (credit to tthomas for this refined design) which removes gdb's limitation of a value having a single [register] location. This is a design alternative, not an implementation alternative. Once we've concurred on the design we can implement it using language-of-the-day. If, in attempting to make these changes we find that the C implementation truly cumbersome then we've a compelling story for language change. 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 happy to actually refactor struct value in this way, but only when using > the proper tool, namely C++. I don't want to complicate things by emulating > classes in C. > > Actually, it appears that this C++ discussion got a bit stalled, apparently since > nobody wants to make the first step. So, how about his plan of action: > > 1. GDB is made compiled with C++ compiler, with resulting errors removed. > 2. I refactor struct value, and folks get to comment if the resulting code > is better, or worse, than what we have. > > Comments? > > - Volodya > > > > >