This is the mail archive of the
mailing list for the GDB project.
Re: Move GDB to C++ ?
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 01 Aug 2008 22:19:51 +0300
- Subject: Re: Move GDB to C++ ?
- References: <487658F7.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20080801131312.GA14712@caradoc.them.org> <email@example.com> <firstname.lastname@example.org>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Vladimir Prus <email@example.com>
> 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
> 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
> 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.