From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5685 invoked by alias); 1 Aug 2008 19:20:30 -0000 Received: (qmail 5656 invoked by uid 22791); 1 Aug 2008 19:20:28 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout3.012.net.il (HELO mtaout3.012.net.il) (84.95.2.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Aug 2008 19:19:57 +0000 Received: from HOME-C4E4A596F7 ([84.229.228.238]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K4X00191SDAKDK0@i_mtaout3.012.net.il> for gdb@sources.redhat.com; Fri, 01 Aug 2008 22:19:59 +0300 (IDT) Date: Fri, 01 Aug 2008 19:20:00 -0000 From: Eli Zaretskii Subject: Re: Move GDB to C++ ? In-reply-to: X-012-Sender: halo1@inter.net.il To: Vladimir Prus Cc: gdb@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <487658F7.1090508@earthlink.net> <20080801131312.GA14712@caradoc.them.org> 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-08/txt/msg00033.txt.bz2 > From: Vladimir Prus > Date: Fri, 01 Aug 2008 20:13:36 +0400 > > Eli Zaretskii wrote: > > > The idea is that a maintainer cannot behave with the code as he > > pleases, claiming that it's his time and therefore his, and only his, > > business. > > > > The idea is also that GDB is a collective effort, so arguments saying > > "I will do this because I like it, and you shouldn't care" are not > > something I'm willing to accept. > > I don't think anybody ever said the phrase you've quoted. Well, that's how I interpreted what you wrote in the message to which I responded. If I misunderstood, I apologize; in that case, please do tell what _did_ you want to say in this passage: > 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? ?? > But I think that objections to any decision in any patch should focus on > specific technical issues, or lack thereof, in the end result. I agree. But then the above text doesn't present any technical arguments, either. It just says (or so I understand it): if one maintainer does something he considers right in the parts of GDB unvisited by others, why not let him do so? This is not a technical issue. > For example, every time I do any nontrivial work, I look at existing code, > and try to see if it can be made more hackable. As result, I might > post a patch that takes a 400-line function and extracts a couple of > fragments into separate functions. You might respond asking why I think > those are the right fragments to extract, whether the names of new functions > makes sense, and so on. But on the other hand saying "don't waste your > time on refactoring, just hack you change in" would seem wrong -- if it's > me doing the work, then I know the most efficient way for me, so as long > as each individual patch makes thing better and the end goal is achieved, > things are OK. In GDB, we do trust each other, but we also have a peer review procedures. During this review, it is quite possible that I (or someone else) would come up and say that what seems like a cool idea to you looks not so cool to me. This isn't mistrust, this is how GDB development works for quite some time. And since you know all that very well, I don't understand why you protest against these very practices on the premise that "if it's me doing the work, then I know the most efficient way for me". > Why should not all technical decisions viewed this way? If I post a patch > that makes use of a C++ feature, then it's reasonable to object if this > feature makes the code more obscure or less maintainable, or increases > GDB footprint. But if none of those issues are present, why prevent me from > using the feature? Or why demand that I prove that use of this feature makes > *me* more productive and whether just hacking the immediate change in would > be faster? Because a decision to switch to another language is much heavier than a decision about a feature of a language that we already use. > The *only* global decision here, is whether to use C++ compiler when building > GDB and I think that decision should be used on purely practical concerns. > Say, if 100 people believe use of C++ features will make them more productive, > 100 people who would not use C++ features anyway, and it turns out that there's > exactly one platform that will not be able to compile GDB if it switches to C++, > and that platform is EOLed in 1980, then I think the decision is clear. Decisions based on beliefs are not at all clear, in my experience. Beliefs are certainly not _practical_ concerns in my book. I did ask for practical arguments (not beliefs), and will be happy to weigh them if they will be ever brought up. > The folks who say they are more productive with C++ are not teenagers, or even > students, so I think it reasonable to trust their opinion about their own > productivity. Do you agree? Yes, I agree. But that is not the issue. We cannot convert GDB to C++ in parts, or at least that's not what is being suggested. The suggestion on the table is to convert everything to C++. So whether this or that maintainer is personally more productive in C++ is only a small part of the arguments for or against the change, because the decision will force _all_ maintainers to work in C++, even those who believe they are less productive in it than in C. > Then, the above statement can be false only if the inconvenience is > as bit as to make the result a net loss. So far, only Mark has > provided concrete concerns -- namely that requiring C++ might make > some targets unviable. Mark was the only one who said why from his POV the switch is unacceptable. I'm saying something else: a decision like that, if it needs to be a good decision, should find good arguments _for_ the change, not only lack of arguments _against_ it. In other words, to me, "why not?" is not a good argument for significant changes such as this one. > Do you know of specific inconveniences that will affect you, personally? I don't see how my personal inconvenience is relevant here. If personal inconvenience is supposed to be the main reason for rejecting changes, I could never object to any change in the GDB manual, for example, because having a less-than-good manual does not personally inconvenience me in any way. But I have proposition for you (and everybody else who thinks it is clear GDB should move to C++): since you evidently have more than enough free time both to maintain your parts of GDB and work on refactoring, how about if you start a branch in the CVS, refactor GDB to C++ there, and show the result? Then we will have two versions of GDB to compare and I believe most of the dispute will die of natural causes because the advantages of one of the versions over the other will be clear to all. Of course, this proposition only stands if the GDB maintenance and routine development don't suffer any significant setbacks due to the additional work on the C++ branch.