Re: Move GDB to C++ ?

[Eli Zaretskii <eliz@gnu.org>]

> From: Vladimir Prus <vladimir@codesourcery.com>
> 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.