Re: Move GDB to C++ ?

[Vladimir Prus <vladimir at codesourcery dot com>]

On Friday 01 August 2008 23:19:51 Eli Zaretskii wrote:
> > From:  Vladimir Prus <vladimir@codesourcery.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?

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?

> > 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".

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, or whether that, in general,
enables to do forthcoming changes faster. If any patch making use
of C++ has specific issues, review should focus on those specific issues.
 
> > 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.

Why? Presumably, because of specific practical issues? Further, those issues
do not exist in vacuum -- those are issues for GDB developers and contributors.
Then, to make any decision, we need to know the issues that specific persons have.
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?

> > 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.  

Ok, good. Then, we've established that at least some folks will be more productive if
we switch to C++. This is what we have on one side of the scale.

> 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++.  

No, I don't think wholesale conversion to C++ is proposed.

> 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.

Yes, this is one of concerns I've mentioned in my original email, and it's
on the other side of the scale. Naturally, it's not possible to prove that 
every current and future maintainer will be as productive in C++ as in C. 
But fortunately, the set of current maintainers and contributors is finite,
and each can speak for himself. 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? 
 
> > 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.

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?

> > 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.

"Inconvenience" was a wrong word. What are negative consequences of the switch
that will affect you as a GDB maintainer in your day-to-day coding?
 
> 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? This thread arises from the
premise that we don't have enough free time to fight with language limitations.

> 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.

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++?

- Volodya