Re: Move GDB to C++ ?

[David Carlton <david.carlton@sun.com>]

I'm not an active GDB contributer any more, so feel free to ignore
anything that I'm saying, but:

I think this discussion is now largely beating around the bush.


Some people strongly prefer to work (on large scale projects) in C,
and really don't want to work in C++.  Some people strongly prefer to
work in C++, and really don't want to work in C.  (And some people
would rather work in Java, or Ruby, or Haskell, but none of those are
realistic options for a GDB transition, so I'm ignoring them.)

Given that, we can talk about technical advantages or disadvantages
until we're blue in the face, but I don't think that will get us any
farther.  We've already seen examples of how GDB is reimplementing
almost every C++ concept that you can think of in C; for the C++ fans,
that's convincing evidence that GDB development would proceed more
smoothly in C++ (those constructs could be done with less work), while
for the C fans, that's convincing evidence that GDB development
doesn't need C (proof by existence).

And I don't see that more examples are going to help much.  I think
Vladimir's proposal of doing one example of a conversion in detail is
sensible enough, but I don't think it will change anybody's feelings
on this matter.  I bet the results will look better to people who like
C++, and unconvincing to people who like C; indeed, Eli's already said
as much for the latter side.

And even if that example did point to significant benefits that C fans
agreed with (or, to take the other side, even if the results didn't
show code that looked significantly different in C than in C++), I'm
not sure that would matter: even if people were intellectually
convinced that their non-preferred language was "better" for GDB,
they'd still be unhappy programming in a language that felt wrong to
them.


I liked it how, at the start of this thread, Mark was very clear: he
doesn't like C++, he has no desire to program in C++, if GDB switches
to C++, he will find something else to work on.  That's what the
choice here looks like to me: you're not choosing implementation
languages, you're choosing contributors, you're trying to figure out
which implementation language will lead to a healthier contributor mix
going forward.

Which language will lead to more people enjoying contributing to GDB?
Which language will lead to more people feeling like they can work at
full productivity while contributing to GDB?  How will the choice of
language affect GDB's institutional memory?  How will the choice of
language affect whether or not newcomers are likely to join in,
whether or not they're likely to stay involved?

I have no idea how to answer these questions. :-(  (Other than running
an experiment by forking GDB.)  But they're what's important here.

David Carlton
david.carlton@sun.com