From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8268 invoked by alias); 29 Jul 2008 17:29:03 -0000 Received: (qmail 8260 invoked by uid 22791); 29 Jul 2008 17:29:02 -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 17:28:43 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KNt00-0007m4-Fj for gdb@sources.redhat.com; Tue, 29 Jul 2008 17:28:36 +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 ; Tue, 29 Jul 2008 17:28:36 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Jul 2008 17:28:36 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Move GDB to C++ ? Date: Tue, 29 Jul 2008 18:08:00 -0000 Message-ID: References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <488F4AA7.7060001@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/msg00301.txt.bz2 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. 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. 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