From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17954 invoked by alias); 2 Aug 2008 09:22:40 -0000 Received: (qmail 17945 invoked by uid 22791); 2 Aug 2008 09:22:38 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 02 Aug 2008 09:22:19 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KPDJW-0003xv-MJ for gdb@sources.redhat.com; Sat, 02 Aug 2008 09:22:14 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Aug 2008 09:22:14 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Aug 2008 09:22:14 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Move GDB to C++ ? Date: Sat, 02 Aug 2008 09:22:00 -0000 Message-ID: References: <487658F7.1090508@earthlink.net> <200808020954.58589.vladimir@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 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/msg00042.txt.bz2 Eli Zaretskii wrote: >> 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. Why? I assume that if C++ switch comes with *no problems* at all, it would not be an issue worth discussing at all. And if it causes some potential problems, then those problems are for either developers or users. I fail to see how a problem that does not affect nobody is a "problem". >> 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. No, we already have a terrible mess of using either macros, or function pointers, or wrapper functions to emulate classes. At no point during gradual transition of those mechanisms the code will be worse than it is now. > And what about new contributions--won't they > also be requested to be written in C++? Presumably, for the cases where code in question is converted to C++, and adding new code requires using C++ features -- yes. For example, if struct value becomes a class with virtual methods, then naturally one would have to use C++ features when adding a new method. For other cases, I don't even see how we can request folks to use C++ -- "you shalt use at least one C++ feature in each patch"? That's neither possible nor desirable. >> 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. Do you think that either: - some developers are not capable of estimating if they personally will be less productive in C++ - there's some other productivity metric other then sum of individual productivity for each developer? >> > 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. The approach for reaching a decision that you outline above sounds good, but it has a problem. There's a big spectrum of approaches. On one side, one can say that C++ is better that C for all purposes, and claim this is valid. On the other hand, one can port GDB to C++, and then have 10 equally skilled programmers implement, individually, multi-process support. 5 would do that in C version, 5 would do that in C++ version, and then you'd compare code size, number of bugs, and time spent. Neither of those extreme approaches seems reasonable to *me* -- but any person has different opinion of what is reasonable enough. I might find that the need to implement multi-process support is concrete goal, and that necessary refactorings of target stack is enough motivation for C++, and somebody else would argue that a complete implementation in C is first needed. There's no universal agreement, so we'll be back to square one -- with everybody having his personal opinion on whether the presented arguments are good enough. In in commercial setting, if you are the boss, you get to decide which level of up-front design or prototyping is sufficient. In GDB, there's no single boss, so we get back to opinions of individuals. If we can't get an agreement on whether C++ is desired, do you think we can get an agreement on what decision making process to use? So my conclusion we're back to individual opinions to the matter. Each person can be either for the change now, or against the change, or ask for additional information, which brings me to... >> 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. ...your personal opinion. Am I right that now you are undecided? What part of GDB do you want to be converted, as example, and what are your criteria for deciding if C++ version is better than the C one? - Volodya