From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-32619-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 11701 invoked by alias); 30 Jul 2008 19:05:00 -0000
Received: (qmail 11691 invoked by uid 22791); 30 Jul 2008 19:04:59 -0000
X-Spam-Check-By: sourceware.org
Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jul 2008 19:04:40 +0000
Received: from HOME-C4E4A596F7 ([84.229.228.238]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K4U00KTQ2BXEK11@i_mtaout2.012.net.il> for gdb@sources.redhat.com; Wed, 30 Jul 2008 22:04:45 +0300 (IDT)
Date: Wed, 30 Jul 2008 19:15:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: Move GDB to C++ ?
In-reply-to: <4890B6BB.7010603@earthlink.net>
X-012-Sender: halo1@inter.net.il
To: Stan Shebs <stanshebs@earthlink.net>
Cc: gdb@sources.redhat.com
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <usktrnqgp.fsf@gnu.org>
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> <4890B6BB.7010603@earthlink.net>
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/msg00333.txt.bz2

> Date: Wed, 30 Jul 2008 11:45:15 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> CC: gdb@sources.redhat.com
> 
> 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.

Can we see some code, please?

> And sure, the same 
> things could be constructed manually in C, but then you're using piles 
> of macro trickery a la vec.h

Are we still talking about ALL_OBJFILES, or about something more
broad?  ALL_OBJFILES is just a loop:

    #define	ALL_OBJFILES(obj) \
      for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)