From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2585 invoked by alias); 14 Jul 2008 16:03:32 -0000 Received: (qmail 2547 invoked by uid 22791); 14 Jul 2008 16:03:31 -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 16:03:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9CD5B2A966E; Mon, 14 Jul 2008 12:03:05 -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 bK3ifbci4O6n; Mon, 14 Jul 2008 12:03:05 -0400 (EDT) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id 7FCC52A961B; Mon, 14 Jul 2008 12:03:05 -0400 (EDT) Message-ID: <487B78B9.2090206@adacore.com> Date: Mon, 14 Jul 2008 16:03: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> <487B52D8.1020802@adacore.com> <200807141953.31008.vladimir@codesourcery.com> In-Reply-To: <200807141953.31008.vladimir@codesourcery.com> 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/msg00157.txt.bz2 Vladimir Prus wrote: >> a) some maintainers dislike for C++ that may reduce their contributions > > Are you sure no maintainer dislike C? I never indicated an opinion on this, let alone that I was sure, indeed this is discussable. > >> 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. Right, but I still think it's a danger that should be discussed > >> 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. Well of course not everyone agrees with the "improper" here, but for sure discussion of ongoing and long term advantages is appropriate >> 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? It's obviously a danger, if you think the danger is minimal, fine, but it is important to make sure that there is a sufficient consensus among all those involved to avoid this. > 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. Not sure what "wards" means here (warts?) but anyway, in the absence of some kind of reasonable estimate of bvenefit/cost ratio, there is a strong argument for the status quo I would think, so I think it is necessary to try to make this estimate, accurate is too strong, but reasonable is reasonable :-) > > 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. Proper documentation is always a good thing, so to the extent that the current issues are to do with undocumented stuff, I would fix them by providinng the documentation before deciding that switching to another language will magically fix the failure to document things well.