From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4077 invoked by alias); 14 Jul 2008 13:21:53 -0000 Received: (qmail 4068 invoked by uid 22791); 14 Jul 2008 13:21:52 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 13:21:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E24EF2A972B; Mon, 14 Jul 2008 09:21:30 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7lUl5ZmFh1G8; Mon, 14 Jul 2008 09:21:30 -0400 (EDT) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id B774C2A9729; Mon, 14 Jul 2008 09:21:30 -0400 (EDT) Message-ID: <487B52D8.1020802@adacore.com> Date: Mon, 14 Jul 2008 13:21:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vladimir Prus CC: gdb@sources.redhat.com Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> <18554.39512.617681.231052@kahikatea.snap.net.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: 2008-07/txt/msg00151.txt.bz2 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 have to take into full account many factors including: a) some maintainers dislike for C++ that may reduce their contributions b) some maintainers who simply don't care to mess with another language c) the danger of unnecessary complex stuff creeping in if there is insufficient control and code review. d) the transition costs are non-negligible 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. 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. 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. However