From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16202 invoked by alias); 30 Jul 2008 07:07:32 -0000 Received: (qmail 16016 invoked by uid 22791); 30 Jul 2008 07:07:30 -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; Wed, 30 Jul 2008 07:07:07 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KO5lz-0006Sq-IG for gdb@sources.redhat.com; Wed, 30 Jul 2008 07:06:59 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jul 2008 07:06:59 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jul 2008 07:06:59 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Move GDB to C++ ? Date: Wed, 30 Jul 2008 07:18: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/msg00314.txt.bz2 Andrew Cagney wrote: > 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? The intent, at least for me, is to be more productive hacking on GDB. One approach to that goal is replacing emulation of classes and exceptions with native language constructs. Another approach is to change internal architecture. And when changing internal architecture, it's desirable to have the help of implementation language. We already have existing architecture that works, and the implementation is truly cumbersome in my opinion. So why spend even more time first redesigning bits of GDB, then implementing new design in C, and then decide that, oh, yes, this is truly truly cumbersome. - Volodya