From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-32618-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 1570 invoked by alias); 30 Jul 2008 18:45:39 -0000
Received: (qmail 1559 invoked by uid 22791); 30 Jul 2008 18:45:38 -0000
X-Spam-Check-By: sourceware.org
Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jul 2008 18:45:18 +0000
Received: from [68.108.140.98] (helo=macbook-2.local) 	by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) 	(envelope-from <stanshebs@earthlink.net>) 	id 1KOGfk-0005Bz-Fi; Wed, 30 Jul 2008 14:45:16 -0400
Message-ID: <4890B6BB.7010603@earthlink.net>
Date: Wed, 30 Jul 2008 19:05:00 -0000
From: Stan Shebs <stanshebs@earthlink.net>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Eli Zaretskii <eliz@gnu.org>
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> <g6njvp$2al$1@ger.gmane.org> <ufxpspkwb.fsf@gnu.org> <488F70E6.7060801@earthlink.net> <uzlnznt4d.fsf@gnu.org>
In-Reply-To: <uzlnznt4d.fsf@gnu.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da9404a2af249b1aa3777080c4b4ab9da22c4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2008-07/txt/msg00332.txt.bz2

Eli Zaretskii wrote:
>> Date: Tue, 29 Jul 2008 12:35:02 -0700
>> From: Stan Shebs <stanshebs@earthlink.net>
>> CC: gdb@sources.redhat.com
>>
>> For instance, at this very moment I'm looking at 
>> ALL_OBJFILES and friends, wondering if the introduction of multiple 
>> execs is going to impact overall performance.
>>     
>
> And how would that change with C++?
>
>   
C++ collection classes would be very effective here. And sure, the same 
things could be constructed manually in C, but then you're using piles 
of macro trickery a la vec.h and you lose all your typechecking etc, or 
if you use function dispatching to iterate, you blow your optimization 
opportunities in code that is known to be time-critical. Good use of C++ 
machinery effectively moves functionality out of the GDB source tree and 
lets the compiler do the work instead.

Stan