From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1539 invoked by alias); 31 Jul 2008 06:11:28 -0000 Received: (qmail 1531 invoked by uid 22791); 31 Jul 2008 06:11:27 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Jul 2008 06:11:08 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KORNN-0006D4-9J for gdb@sources.redhat.com; Thu, 31 Jul 2008 06:11:01 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Jul 2008 06:11:01 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Jul 2008 06:11:01 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Move GDB to C++ ? Date: Thu, 31 Jul 2008 08:40:00 -0000 Message-ID: References: <487658F7.1090508@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 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/msg00343.txt.bz2 Stan Shebs wrote: > As many know, there is a project afoot to investigate the recoding of > GCC from C into C++. I believe the C++ idea was briefly touched on for > GDB at the summit, although I don't remember much discussion. Anyway, > this would be a good time to start thinking about it, and if people are > generally in favor of the idea, we can start small by tweaking the > sources to be C++-friendly, avoiding keywords and so forth; GCC has a > new warning flag -Wcxx-compat that can help. > > For my part, I think we should do it. GDB has quite a bit of object-like > structure internally, and while in the past it was taking a bit of a > chance to rely on the availability and reliability of C++ compilers, > those concerns are now generally outdated; I'm not sure any of the > potential problem hosts are even supported any longer. I think this discussion went a bit wrong way -- trying to convince folks that *investing effort* in converting to C++ is justified. However, I don't think the proposal is about making folks not interested in C++ doing any work -- the proposal is about allowing folks who do some specific work, and want to make use of additional features C++ provides, to use those features, while not imposing significant problems on the rest of contributors. Let me give an example. I believe that using C++ in varobj.c would allow to reduce the amount of code; so should I need to add new "method" to varobj, I'd like to convert from current emulation of classes to C++ classes. The only folks who actively touch that file are Nick and myself. Assume Nick does not mind. Then, why not allow me to use C++ for that module? Some possible reasons: 1. It would require having C++ compiler when building GDB. This, of course, maybe be issue for companies who provide GDB on exotic platforms. The issue can be discussed, or it can be discarded on the ground that this is list for FSF GDB, and FSF makes gcc as well. 2. Not everybody knows C++, so if I'm hit by a bus, not everybody will be able to adopt this module. (This is obviously more important for core parts than for MI). I'm not sure if this aspect is critical -- I get the impression that even those who object to C++ actually knows the language. 3. Misusing C++ features can make the code totally unmaintainable. However, misusing C can have the same effect. As all patches are posted, anybody can object when such misuse of C++ features happens. The same mechanism can be used to object to C++ features not universally known to GDB developers. So, it seems to me that there is a group of people that will benefit from switch to C++, and the inconvenience for people not willing to invest any time into this project will be minimal. Sounds like an overall gain, no? - Volodya