From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5243 invoked by alias); 14 Jul 2008 16:23:37 -0000 Received: (qmail 5232 invoked by uid 22791); 14 Jul 2008 16:23:36 -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 16:23:18 +0000 Received: (qmail 13132 invoked from network); 14 Jul 2008 16:23:16 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jul 2008 16:23:16 -0000 From: Vladimir Prus To: Robert Dewar Subject: Re: Move GDB to C++ ? Date: Mon, 14 Jul 2008 16:23:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb@sources.redhat.com References: <487658F7.1090508@earthlink.net> <200807141953.31008.vladimir@codesourcery.com> <487B78B9.2090206@adacore.com> In-Reply-To: <487B78B9.2090206@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807142023.04952.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/msg00163.txt.bz2 On Monday 14 July 2008 20:03:05 Robert Dewar wrote: > 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 you're falling into a trap common for planning large transitions. It seems reasonable to prepare of list of points, and compare alternatives on each point. However, I never saw this work, because even if you and I agree on one specific point, there's slim chance that 10 different people will all agree on that single point. And if there are 10 different points to discuss (with varying importance) and 20 different people (with varying degree of involvement, and varying backgrounds, and varying opinions about the importance of the points), how do you come with a clear "yes"/"no" result? Most transitions I saw involved: 1. A few folks pushing for specific solution that improves on the current status quo. 2. Other folks expressing opinions like "we absolutely need XXX" So, here, what are your most important concerns? Do you see those concerns can be mitigated, or not? > > > > 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. The problem is the book named "The C++ Programming Language" went through at least 3 revisions, presumably with extra help of professional editors. Do we want to beat that? And why newcomers who already read this book should read the documentation for our non-standard mechanisms. - Volodya