From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7532 invoked by alias); 9 Apr 2012 23:23:59 -0000 Received: (qmail 7524 invoked by uid 22791); 9 Apr 2012 23:23:58 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Apr 2012 23:23:46 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SHNw1-00040R-9H for gdb@sourceware.org; Mon, 09 Apr 2012 19:23:45 -0400 Message-ID: <4F836F72.8080700@earthlink.net> Date: Mon, 09 Apr 2012 23:23:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> In-Reply-To: <87aa2rjkb8.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da9404b6ba8fc2c81b3821f0489db78487c01350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00067.txt.bz2 On 4/4/12 1:47 PM, Tom Tromey wrote: > > At the GCC Summit, I once again brought up the perennial idea of > moving GDB to be implemented in C++. There, we agreed that as a > follow-on to that discussion that I would raise the topic among the > GDB maintainers, and in particular present my migration plan. I support this plan. Many of the existing poor-cousin bits of infrastructure date back to a time when C++ was not a viable candidate for a widely-available tool, and others, more recent, are conscious imitations of C++ capabilities. At this point it starts to look a little perverse that we are doing a half-million-line program in C. The changes will be low-impact, perhaps even less visible than the K&R/ANSI C compatibility hacks that we maintained for so long. A secondary benefit will be that it opens up the use of minor C++ features, without getting us into the C90-vs-99 dilemma that has kept us from taking advantage of those. > > I don't believe we should convert all of GDB to C++. In particular I > think gdbserver should remain as pure C, and likewise any code shared > between gdbserver and gdb should be kept as such. I don't know that it matters that much for GDBserver anymore. When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today. Plus I note that GDBserver is picking up a load of functionality, and the truly space-conscious are better-advised to build a custom stub that is stripped down to just the bits they're going to use. Stan