From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11798 invoked by alias); 6 Apr 2012 15:34:37 -0000 Received: (qmail 11325 invoked by uid 22791); 6 Apr 2012 15:34:36 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TO_NO_BRKTS_PCNT X-Spam-Check-By: sourceware.org Received: from shell4.bayarea.net (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Apr 2012 15:34:04 +0000 Received: (qmail 28380 invoked from network); 6 Apr 2012 08:34:02 -0700 Received: from c-76-102-3-160.hsd1.ca.comcast.net (HELO redwood.eagercon.com) (76.102.3.160) by shell4.bayarea.net with SMTP; 6 Apr 2012 08:34:02 -0700 Message-ID: <4F7F0CEA.5000206@eagerm.com> Date: Fri, 06 Apr 2012 15:34:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++? Not. 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> In-Reply-To: <20120406131619.GI27438@adacore.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00055.txt.bz2 On 04/06/2012 06:16 AM, Joel Brobecker wrote: >>> I do not recommend that GDB use C++. >> >> I agree 100% on all points. I came to the same conclusions 10 years >> ago. Everything i do now is C, and i only poke with C++ to grab >> something out of it or to reverse engineer. > > I wish we would stop discussing about the language itself, and argue > the technical points that the pro-C++ camp were bringing up. There are > a number of issues with GDB's design there were raised, and solutions > involving the use of C++ were proposed. As far as I know, the anti-C++ > camp has rejected C++ in general based on general and vague arguments, > rather than argue the specific points that have been brought up. We are > NOT talking about using ALL of C++, we are talking about using > a reasonable subset that would allow us to expand a bit what the language > can do for us. I'll echo Joel -- complaints about C++ language design don't add much to the discussion. I've long been an advocate of C With Classes. I'm less in favor of using other features in C++, perhaps not so much from the technical concerns, which I do have, but because gcc provides horrible C++ error messages and gdb provides horrible C++ debugging. It's been suggested that if gcc/gdb converted to C++ that both would improve as the developers ate their own dog food. > And yet, that's exactly what we are doing: > - unit elaboration; > - gdbarch/language dispatching > - exception handling > - use of unions to emulate polymorphism; > - etc, etc, etc. Writing several different versions of object-oriented C to implement these features doesn't make gdb easier to debug or extend. > So again, the proposal that was put on the table a long time ago > was that some specific features of C++ be used in order to simplify > certain areas of GDB's code. The pro-C++ camps has, in my opinion, > successfully shown how C++ was going to help. The specific arguments, > in my opinion, should be brought up again, and those specific arguments > should be discussed, rather than just discussing generalities about > how horrible C++ is. > >> All it requires is a few more short lines of explanatory design >> notes scattered through the code and clarity of thought. In many places, gdb comments and descriptions range from meaningless to useless. The internals document is far out of date. In many areas, it is difficult to understand why the code does the odd things it does. I'm not sure where "clarity of thought" would be applied. Working in gdb is not easy. It doesn't seem to be getting better. There are many changes which, IMO, would reverse this trend. One would be to rewrite the parts which are currently written in object oriented code with incomplete encapsulation with clear C++ classes and member functions. Several parts of gdb are overly complex and would benefit from refactoring and redesign. As parts are converted to C++, perhaps this would give the opportunity for a long overdue review of the design. There's been an argument that poorly written C++ code is the only possible outcome of converting gdb to C++. I don't think that this is the inevitable result. Developers can write good C or good C++, as well as poor C or poor C++. Especially with gdb maintainers' concerns for the quality of C++ code, I would expect that converting gdb to C++ would favor (if not demand) producing good C++ rather than just checking in anything submitted. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077