From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20670 invoked by alias); 14 Jul 2008 15:54:03 -0000 Received: (qmail 20622 invoked by uid 22791); 14 Jul 2008 15:54:02 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 15:53:44 +0000 Received: (qmail 8843 invoked from network); 14 Jul 2008 15:53:42 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jul 2008 15:53:42 -0000 From: Vladimir Prus To: Robert Dewar Subject: Re: Move GDB to C++ ? Date: Mon, 14 Jul 2008 15:54:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb@sources.redhat.com References: <487658F7.1090508@earthlink.net> <487B52D8.1020802@adacore.com> In-Reply-To: <487B52D8.1020802@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807141953.31008.vladimir@codesourcery.com> 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/msg00154.txt.bz2 On Monday 14 July 2008 17:21:28 Robert Dewar wrote: > Vladimir Prus wrote: > > Nick Roberts wrote: > > > >> > Tom> * Templates are used in at least one place -- vec.h. > >> > > >> > I found another gdb-specific example of this: observers. A given > >> > observer is essentially an instance of a template class. > >> > >> From my point of view, another benefit of using C++, is presumably that > >> variable objects could be represented as linked lists, rather than use the > >> current vector API which, for reasons I've already given, I think is > >> unsuitable. > > > > Without getting into that discussion again, it's clear that either std::vector, > > or std::list, or std::deque, are much better than anything implementable in C. > > Sure, but that's a narrow view from the language point only. You might want to note that I was replying to Nick comments about data structures only; whereas I have a more broad opinion about C++, I was not trying to express it here. > You have to > take into full account many factors including: > > a) some maintainers dislike for C++ that may reduce their contributions Are you sure no maintainer dislike C? > c) the danger of unnecessary complex stuff creeping in if there is > insufficient control and code review. We already have unnecessary complex stuff, which is poorly documented in sources, and not documented in any lecture courses or books. Like, exceptions and cleanups. > b) some maintainers who simply don't care to mess with another language > > d) the transition costs are non-negligible You might want to note that the ongoing cost of using improper tools are not zero, either. > > e) the increased commplexity of the environment necessary to build > GDB. Speaking a moment from AdaCore's point of view as an example, > this would mean we had to build and maintain C++ compilers on dozens > of configurations. We can probably do this, but it is not zero work, > and I have no idea how other organizations would be affected. > > f) the danger that points a) through e) together might lead to a > divergence in the development path. This is strong statement. Do you have the evidence that such a divergence will happen among those folks who *actively* contribute things? > My inclination is that the minuses outweigh the pluses. > > To make this point clearer, suppose I suggested we recode the > whole of GDB in Ada. From purely a language point of view, the > technical arguments in favor of such a recoding would be very > strong, and indeed I would be happy to argue and demonstrate > that from purely a language point of view, this would be a > better choice than C++. > > However, everyone (including me) would agree that in this case > a) through f) would outweigh any technical langauge advantage, > so much so that the proposal would not be considered seriously > at all. Well, there are obvious *practical* differences between C++ and Ada, which makes C++ more viable for any codebase presently in C. > > Obviously the transition from C to C++ would be easier, but I > see too much of the argument focused on the language advantages, > and not enough on the balance of the negative and positive points. I think that it's pretty much impossible to get accurate estimate of benefit/cost ratio, especially when benefit includes such abstract things as developer's productivity, and elimination of the current wards, especially wards for potential new contributors. I think that in this case, the most important argument is that GDB already uses most of the features C++ has to offer -- except in non-standard and undocumented way. Switch to C++ will make that better. The only price to pay is requiring C++ compiler -- and given that the GNU project makes GCC, I just don't see the issue. - Volodya