From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11022 invoked by alias); 6 Apr 2012 00:35:12 -0000 Received: (qmail 10727 invoked by uid 22791); 6 Apr 2012 00:35:11 -0000 X-SWARE-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BAYES_20,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 00:34:58 +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 q360Yo0m007419; Thu, 5 Apr 2012 17:34:50 -0700 Message-Id: <201204060034.q360Yo0m007419@new.toad.com> To: Phil Muldoon cc: mark.kettenis@xs4all.nl, gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++? Not. In-reply-to: <4F7D8603.90801@redhat.com> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <201204042155.q34LtJNB013402@glazunov.sibelius.xs4all.nl> <4F7D8603.90801@redhat.com> Comments: In-reply-to Phil Muldoon message dated "Thu, 05 Apr 2012 12:46:11 +0100." Date: Fri, 06 Apr 2012 00:35: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/msg00051.txt.bz2 I introduced many of the "tables of C pointers" into GDB. I could've opted to switch to C++ at that point. I did not and am happy that I did not. The paradigms we introduced were simple, maintainable, useful, and documented. I see nothing wrong with writing in C and occassionally using a table of pointers (like the dispatch tables in BFD, or the target selectors) where appropriate. Just because you sometimes call through a pointer, or arrange values in data structures, doesn't mean you need to "move to an object oriented language". People who can't do object-oriented programming in a procedural language perhaps don't understand object-oriented programming, which is not about syntax, nor about enforcement, but about deliberately choosing a narrower subset of mechanisms to produce programs that are easier to maintain. One of our original reasons for sticking with C is less relevant today. GDB is one of the first programs you want to bring up on a new system, since it can help you debug itself and every other program. To be useful for that, it needed to be compilable with a very broad spectrum of relatively simple compilers. Being written in C++ would have foiled that. Nowadays we merely cross-compile and cross-debug, or emulate the target system from some well-supported host system. Avoiding the need for a tricky, complicated, and working compiler to compile GDB is less of a constraint. I have not yet found an easy-to-maintain large production C++ program; not in 1991 and not in the intervening 20 years. I've written a medium sized C++ program (smqueue). Based on that experience, I was never tempted to write a large program in C++. I have found many C++ programs that are hard to maintain. Hard to understand, hard to compile, hard to debug. As an example, I am currently wrestling with a commercial success, a production program running at thousands of sites, that took 12 years of a team of half a dozen programmers to write and maintain in C++. It now no longer even compiles, because the recently graduated programmers who wrote it embedded questionable C++ constructs deep into its infrastructure, and failed to document the structures they were building. I could and will rewrite the broken parts, but it's very painful to even understand what they were TRYING to do, because it's undocumented and wrapped up in layer after layer after layer of templates and inclusion and C++ junk. They aren't making objects that have accessors and such; they're using a "pattern language" that abuses C++ objects to do cheap runtime type-checking -- or something! It took hours to just narrow the program down to a one-page program that would reproduce the compiler error while being something a human could grasp. Of course every C++ programmer denies that they are designing or writing a monster like that. However, a surprising number end up that way. It is much harder to screw up a C program beyond human recognition. There's not even a contest for Obfuscated C++, since it's trivial to do without even intending to! C++ fails at simplicity and predictability. The 1990's idea that C++ was the obvious successor to C has clearly been proven false over the last 25 years. C is still here and going strongly. C++ was an experiment that disproved its thesis -- a valuable contribution, certainly, but not an example to follow. Even the thesis that objected oriented programming is superior to traditional procedural programming has been disproved (in my mind), or is at least unresolved at this date. I would say that over the last 20-40 years the key new insights in programming have been in portability, simplicity, and pan-global collaboration of focused teams (version control, automating distributed discussions and bug reports, distribution, packaging, etc). The mainstream of system and application development continues in directions other than C++, such as C, Java, and Python, not to mention big corners like PHP, C# and Objective-C. If you ended up writing parts of GDB in C++ and other parts in C, anyone who did maintenance on it would have to understand both. But C++ is full of ugly traps for the unwary, and things seldom mean what they appear to a C programmer to mean. You'd narrow your potential pool of talented contributors. And you'd be basing your core debugger on one of the least well supported parts of C++ -- its interoperability with traditional C code. I do not recommend that GDB use C++. John