Re: Move GDB to C++ ?

[Vladimir Prus <vladimir at codesourcery dot com>]

Eli Zaretskii wrote:

>> Date: Fri, 1 Aug 2008 09:13:12 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> Cc: Vladimir Prus <vladimir@codesourcery.com>, gdb@sources.redhat.com
>> 
>> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
>> > > From:  Vladimir Prus <vladimir@codesourcery.com>
>> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
>> > > 
>> > > 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.
>> > 
>> > Your being busy refactoring does impose a significant problem on me.
>> > We are members of the same team, so how you use your time while on the
>> > team is important to me.
>> 
>> Could you please expand on this idea?
> 
> 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. You, as a global
maintainer can care about any patch posted to gdb-patches as you see fit.
But I think that objections to any decision in any patch should focus on
specific technical issues, or lack thereof, in the end result. 

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.

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?

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. And
it that case, the first 100 people need to convince the other 100 people that
they should use C++ features -- they are happy not to.

 >> GDB is a GNU project, driven by volunteers and sponsored contributors.
>> And the sponsored contributors are volunteers from the perspective of
>> anyone outside the sponsoring organization.  I don't understand the
>> objection to other people choosing to invest effort on something, even
>> if you think it's unimportant.  Volunteer projects go where their
>> volunteers want to take them!
> 
> We are not talking about just any change here.  We are talking about a
> change that will affect everyone.  Taking a volunteer project in such
> directions without consensus isn't right, IMO.  Vladimir's message in
> effect tried to side-step the lack of consensus, which is not how I
> thought GDB development should advance.

It's not exactly true; I there are various consensuses that are possible.
It seems to me like we were trying to reach concensus on the following
statement:

    "Everybody should stop doing anything, quit their jobs, go to desert,
    and hack on converting GDB to C++ without rest"

Naturally, this is not a defensible statement, and I think the statement to
discuss is:

    "There's quite a number of people who say they will be more productive
     using C++ and C++ will bring little inconvenience to the rest, so
     allowing using C++ is a net gain"

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

Do you know of specific inconveniences that will affect you, personally?

- Volodya