From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2304 invoked by alias); 3 Jul 2007 19:09:07 -0000 Received: (qmail 2296 invoked by uid 22791); 3 Jul 2007 19:09:06 -0000 X-Spam-Check-By: sourceware.org Received: from mail.intrepid.com (HELO mail.intrepid.com) (74.95.8.113) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jul 2007 19:09:04 +0000 Received: from DELORIAN ([10.10.10.10]) by mail.intrepid.com (8.13.8/8.13.8) with ESMTP id l63J92NJ030844 for ; Tue, 3 Jul 2007 12:09:02 -0700 From: "Gary Funck" To: Subject: RE: GDB in C++ Date: Tue, 03 Jul 2007 19:09:00 -0000 Message-ID: <00b601c7bda5$a5e6fa60$0a0a0a0a@DELORIAN> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <468A3DA6.2010806@adacore.com> 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: 2007-07/txt/msg00031.txt.bz2 Robert Dewar wrote (in part): > What is needed is an argument that the advantages outweigh > the disadvantages. Arguments based solely on the value of > the resulting style improvements are inadequate for me > unless framed in these terms. Although I am sympathetic to the idea of re-implementing GDB in C++, and have mentioned this to Mike Eager off-list, perhaps it would be worth understanding why this change is being recommended now, and why it has been recommended previously. Based on my experience working on GDB, I relate the suggestion to re-implement GDB in C++ to the suggestion that the internal documentation be improved. I think that both suggestions are motivated by the desire to make it is easier to understand GDB's source code, and to modify and improve it. In the long run, anything that makes GDB easier to understand and to improve will lead to a faster pace of development, and likely improvements in usability and reliability. If we agree that making GDB easier to understand and to change are worthwhile goals, then perhaps the discussion should focus on what are the best and least expensive (in time, effort, and impact on reliability) methods for achieving those goals? I think that one of the appeals of recasting some of GDB's internal object-like constructs into C++, using a C++ object-oriented style is that this activity is seen as something that a small group of individuals can do in a reasonable amount of time and that it might result in an infrastructure that is easier to understand and to extend. Further, there may be reliability improvements because C++ will better enforce the object-oriented constraints. If C++ isn't the answer, and keeping all of GDB in "C" is a fixed point, what changes would the developers recommend that would offer similar (perceived) improvements in understandability and extensibility?