From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13315 invoked by alias); 31 Jul 2008 08:40:53 -0000 Received: (qmail 12991 invoked by uid 22791); 31 Jul 2008 08:40:38 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Jul 2008 08:40:18 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id 6E03620545 for ; Thu, 31 Jul 2008 10:40:15 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id 53C0C2047F for ; Thu, 31 Jul 2008 10:40:15 +0200 (CEST) From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb@sourceware.org Subject: Re: Move GDB to C++ ? Date: Thu, 31 Jul 2008 09:03:00 -0000 User-Agent: KMail/1.9.9 References: <487658F7.1090508@earthlink.net> <4890B6BB.7010603@earthlink.net> <200807301942.m6UJgH6s005159@brahms.sibelius.xs4all.nl> In-Reply-To: <200807301942.m6UJgH6s005159@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807311042.41954.apoenitz@trolltech.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: 2008-07/txt/msg00344.txt.bz2 On Wednesday 30 July 2008 21:42:17 Mark Kettenis wrote: > > 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 > > You mean the C++ STL container classes? Yes they make it easy to > write code. And they make it easy to choose the right container for the task, e.g. the one with the needed performance characteristics. In C, one basically starts of with a linked list, and only if it really, really hurts to a degree that one can't ignore the problem > But they don't really help when you need to debug your > code since they are implemented using templates. It's somewhat funny to hear that kind of argument from someone who is writing debuggers. Isn't it your self-assigned task to make debugging easy? If it isn't easy (and I do agree that debugging common C++ with plain gdb is a pain), it is - sorry to be blunt - at least partially your fault. Instantiated class templates are not different from ordinary structs, and there is no real problem in presenting the "children" of a, say, std::list as if they were ordinary struct members, at least for a given (say, current gcc's) implementation. > The result is incomprehensible compiler errors when you make > a mistake in your code. Well, at the time I started coding (and probably yours, too ;-)), compiler were considered "user friendly" when they did not just abort on faulty input but were so nice and gave the number of the problematic line, too. (a) one gets used to it, and (b) it's far more convienient nowadays. Especially gcc is pretty good at pointing out possible reasons _why_ compilation failed. > And every time I need to look at such a container in GDB I spend > minutes and minutes figuring out how to display its contents. See above. That's the problem of the frontend you use. Of course, one reason that most frontends do not display container contents nicely is that gdb is not easy to interact with programmatically, and behaviour details change by the release, so frontend writers are likely to skip that part and just present you the C view of the world. > I'm not a fan of macro trickery a la vec.h either. I think actually > "open coding" your containers is preferable in many cases. Linked > lists and dynamically sizable arrays aren't too difficult to > implement of you only need them for two or three different types. And a hash map might be the proper choice for a container performance-wise, and you are lost with "openly coded plain C". > > if you use function dispatching to iterate, you blow your optimization > > opportunities in code that is known to be time-critical. > > Do you have any evidence to back this up? As far as I understand the > main optimization strategy for C++ is heavy use of inlining. This > increases the code footprint of your code which in turn blows away > your instruction cache. That's a heavy price to pay for avoiding a > few branch instructions and some stack access. Gdb performance is an issue. I have projects were starting up gdb easily takes 20 seconds or more. The same code shows up in the debugger from the Dark Side in a snap. > My experience is the exact opposite. Behind that simple assignment > might hide a very costly operation. First off all, not all such operations are on the critical paths in the application, so there usually lots of places where an expensive 'a = b;' might waste a few hundred CPU cycles over the optimal, 20 line, highly optimized "manual copy"; but the latter wastes the developer's time, the reviewer's time and the code reader's time, and human time is usually regarded more valuable than CPU time. In the other cases, the profiler will tell you, and it's up to you to decide whether it's worth that price in that situation and whether you need hand-craft this particular piece of code. Or simply optimize the container you use _without_ touching the "user code". That's a liberty you do not have with "openly coded" structures. > > Good use of C++ machinery effectively moves functionality > > out of the GDB source tree and > > lets the compiler do the work instead. > > Pushing compile time through the roof and gobbling up several hundred > of megabytes of memory. Will it still be possible to compile a native > GDB on an underpowered ARM CPU with 64MB of memory? Yes. Andre'