From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17094 invoked by alias); 6 Apr 2012 23:32:38 -0000 Received: (qmail 17085 invoked by uid 22791); 6 Apr 2012 23:32:36 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_BRBL_LASTEXT,RCVD_IN_HOSTKARMA_YE,RCVD_IN_NJABL_RELAY,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from new.toad.com (HELO new.toad.com) (209.237.225.253) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Apr 2012 23:32:23 +0000 Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q36NW90m006330; Fri, 6 Apr 2012 16:32:09 -0700 Message-Id: <201204062332.q36NW90m006330@new.toad.com> To: Joel Brobecker cc: gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++? Not. In-reply-to: <20120406131619.GI27438@adacore.com> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <201204042155.q34LtJNB013402@glazunov.sibelius.xs4all.nl> <4F7D8603.90801@redhat.com> <201204060034.q360Yo0m007419@new.toad.com> <4F7E4849.1090104@netspace.net.au> <20120406131619.GI27438@adacore.com> Comments: In-reply-to Joel Brobecker message dated "Fri, 06 Apr 2012 06:16:19 -0700." Date: Fri, 06 Apr 2012 23:32:00 -0000 From: John Gilmore 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: 2012-04/txt/msg00056.txt.bz2 > And yet, that's exactly what we are doing: > - unit elaboration; > - gdbarch/language dispatching > - exception handling > - use of unions to emulate polymorphism; Writing modular programs is a good idea even if we don't do it in C++. I have heard it claimed that many techniques of modular programming were even invented before C++ existed - though that may be doubted. If people have the energy to rewrite large chunks of GDB, why argue about it? Go off and do it. It's free software -- you don't even have to start from scratch like GNU did. The world can always use a new debugger. You can make a politically correct debugger (pcdb?) with an identical interface but a C++ implementation under the hood. If it's better than GDB in the long run, maintainers will migrate to it, GDB will fall into disrepair, and GNU will adopt it. It's always easier to see how a completely paper design is cleaner than a piece of running code whose warts are in front of you. And it means you can respond to critics by saying, "See - you can't find any problems in our nonexistent code, you are just making generalized statements about the implementation language, which we should all ignore as irrelevant." By the time you actually get the new design working, it too will have compromises, bugs, and won't match its documentation. Then again, if you had put that prodigious energy into updating the original piece of running code, perhaps it would have fewer bugs, fewer compromises, and updated documentation. John PS: Which particular unions in gdb are you complaining about ("used to emulate polymorphism")? I grepped the sources, and see a bunch used in BFD, in SIM, and in GDB's expression parser. It seems to me that they are all used to unify storage and access to disparate types of elements in a list or array -- not to make or fake polymorphism. This is what unions were designed for. Did I miss some corner where unions are cowering under the lash of abuse? PPS: What is "unit elaboration" and what does that have to do with GDB? All I can find from a quick web search is that it has something to do with Ada. Perhaps other languages don't do it -- or have another name for it. "Linking"? Are you sure we shouldn't rewrite bits of GDB in Ada instead of C++?