This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Move GDB to C++ ?
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