From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14481 invoked by alias); 16 Jun 2010 17:10:35 -0000 Received: (qmail 14473 invoked by uid 22791); 16 Jun 2010 17:10:34 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jun 2010 17:10:28 +0000 Received: (qmail 3067 invoked from network); 16 Jun 2010 17:10:26 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jun 2010 17:10:26 -0000 Message-ID: <4C19057D.8090607@codesourcery.com> Date: Wed, 16 Jun 2010 17:10:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: xingxing pan CC: gdb@sourceware.org Subject: Re: Why isn't GDB designed and implemented by using Object-Oriented methodology? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2010-06/txt/msg00057.txt.bz2 xingxing pan wrote: > When meeting so many structs and function pointer in the source codes, > dose anyone have the thought to redesign and implement GDB using > Object-Oriented methodology? > Well, the target vector abstraction dates from 1990, so that means we've been redesigning GDB to use object-oriented methodology for the past twenty years or so. In practice, the hard part for us is deciding what the objects *should* be. If someone posted a mega-patch tomorrow that converted GDB to C++ written in good style, that wouldn't do a thing to help me figure out how to support changing properties of tracepoints while a trace is running, or how to speed up symbol reading for really large executables, or how to reliably install software breakpoints with the inferior running in a non-stop mode. So yes, more OOM "would be nice" and we encourage the submission of patches going in that direction, but it's not the magic bullet that will magically make GDB easy to work on. Stan