From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13979 invoked by alias); 30 Jul 2008 19:30:09 -0000 Received: (qmail 13955 invoked by uid 22791); 30 Jul 2008 19:30:08 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-dupuy.atl.sa.earthlink.net (HELO elasmtp-dupuy.atl.sa.earthlink.net) (209.86.89.62) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jul 2008 19:29:48 +0000 Received: from [68.108.140.98] (helo=macbook-2.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KOHMm-0002OE-JP; Wed, 30 Jul 2008 15:29:44 -0400 Message-ID: <4890C127.80404@earthlink.net> Date: Wed, 30 Jul 2008 19:42:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Eli Zaretskii 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> <488F70E6.7060801@earthlink.net> <4890B6BB.7010603@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940f460b5e6a8589f639b35a3472ccb4625350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00336.txt.bz2 Eli Zaretskii wrote: >> Date: Wed, 30 Jul 2008 11:45:15 -0700 >> From: Stan Shebs >> CC: gdb@sources.redhat.com >> >> Eli Zaretskii wrote: >> >>>> Date: Tue, 29 Jul 2008 12:35:02 -0700 >>>> From: Stan Shebs >>>> 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? > How can I do that meaningfully? It depends on how everything else is to be designed. I'm a little surprised that you don't see it yourself, actually. >> 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) > It's the the "and friends" part that is problematic, there are a dozen variants at least, and the potential for doubling that number with multiple execs, because sometimes you still want to iterate through all indiscriminately, other times through only the objfiles for a particular program. There is even a note in objfiles.h about the hazards of the basic "pointer to next" approach, which was the very height of C fashion twenty years ago, but is actually a chronic source of bugs and memory leaks. Stan