From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28805 invoked by alias); 2 Aug 2008 08:07:00 -0000 Received: (qmail 28795 invoked by uid 22791); 2 Aug 2008 08:06:59 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout4.012.net.il (HELO mtaout4.012.net.il) (84.95.2.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Aug 2008 08:06:39 +0000 Received: from HOME-C4E4A596F7 ([84.229.228.238]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K4Y00KTBRTX0RF0@i_mtaout4.012.net.il> for gdb@sources.redhat.com; Sat, 02 Aug 2008 11:05:58 +0300 (IDT) Date: Sat, 02 Aug 2008 08:07:00 -0000 From: Eli Zaretskii Subject: Re: Move GDB to C++ ? In-reply-to: <200808020954.58589.vladimir@codesourcery.com> 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> <200808020954.58589.vladimir@codesourcery.com> 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/msg00041.txt.bz2 > From: Vladimir Prus > Date: Sat, 2 Aug 2008 09:54:57 +0400 > Cc: gdb@sources.redhat.com > > The statement you've quoted is not complete, and is followed by quite some text, ending > with the the following: > > So, it seems to me that there is a group of people that will benefit from switch to C++, > and the inconvenience for people not willing to invest any time into this project will > be minimal. Sounds like an overall gain, no? This just reiterates what you said in the part I cited. I still don't see how I should have interpreted your text differently. You are saying that a benefit to a single maintainer in the area where others either don't mind or don't work is a reason good enough to change the development paradigm in that area. I disagree. > Those practices never resulting in anybody questioning me if I use my > time most efficiently. I was never asked to prove that refactoring code, > in general, results in easier forthcoming changes in that code area. Then, > I'm surprised that you want me to prove that converting some specific > bits to C++ is the most efficient use of my time "our time", not "my time". > > Because a decision to switch to another language is much heavier than > > a decision about a feature of a language that we already use. > > Why? Presumably, because of specific practical issues? I already explained those practical issues, in so many words, in this thread. I have nothing to add to what I said. > Do you agree that if no GDB developer or use can name any issue with C++ > that will cause him problem, or make him less productive, then it's OK to switch? No, I don't agree. A good decision has nothing to do with problems caused to the developers individually. > No, I don't think wholesale conversion to C++ is proposed. How can a program such as GDB be converted to C++ in parts? Can you show a practical plan of doing that? Apart of making C code compatible with a C++ compiler, the rest should be done at once, or else we will have a terrible mess of C++ and C that is actually worse of what we have today. And what about new contributions--won't they also be requested to be written in C++? > Do you agree that if no maintainer will say he's less productive in > C++ than in C, then we can trust them, and no productivity loss will > result? No. > > 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. > > As we've already established, quite a number of people will be more productive > in C++, which I think is sufficient "pro" to start more detailed process of > collecting pros and cons. You, on the other side, want some stronger "pro" > before even trying to list cons. Why? Again, I already explained why elsewhere: Each change of development environment has a non-trivial overhead. To justify that overhead, a set of specific development goals should be stated, and then an analysis should be made whether the way to reach those specific goals will be easier by first changing the environment, and by how much easier. Just improved productivity is not a reason that is good enough, because productivity is not a goal in itself, it's a means. For example, if no important developments are expected for years to come, just maintenance, then productivity is not important. > What are negative consequences of the switch that will affect you as > a GDB maintainer in your day-to-day coding? None whatsoever. But my _personal_ problems with this switch have nothing to do with a sane method of making decisions like this one. > > 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, > > Was this passage meant to sound sarcastic? No, not at all. > This thread arises from the > premise that we don't have enough free time to fight with language limitations. Then how can we afford to spend effort in converting code to C++? > You are right that having the concrete code would help. But, did not I already > suggested to prepare a patch showing use of C++ for some specific area? Or > you suggest to convert every single file to C++ idioms before any kind of further > discussion? Naturally, there's certain number of changed lines after which merges > between two codebases will become too hard, so we'll have a fork as result. I don't > think anybody in this thread wants that to happen, so maybe a local patch for > some part of GDB, or several patches, is a better way to evaluate effects of C++? I've been suggesting this since the beginning: let's have specific examples of non-trivial parts of GDB that will show how C++ is better than C, both for maintenance of existing code and for future development.