Re: Move GDB to C++ ?

[Vladimir Prus <vladimir@codesourcery.com>]

On Monday 14 July 2008 17:21:28 Robert Dewar wrote:
> Vladimir Prus wrote:
> > Nick Roberts wrote:
> > 
> >>  > Tom> * Templates are used in at least one place -- vec.h.
> >>  > 
> >>  > I found another gdb-specific example of this: observers.  A given
> >>  > observer is essentially an instance of a template class.
> >>
> >> From my point of view, another benefit of using C++, is presumably that
> >> variable objects could be represented as linked lists, rather than use the
> >> current vector API which, for reasons I've already given, I think is
> >> unsuitable.
> > 
> > Without getting into that discussion again, it's clear that either std::vector,
> > or std::list, or std::deque, are much better than anything implementable in C.
> 
> Sure, but that's a narrow view from the language point only. 

You might want to note that I was replying to Nick comments about data structures only;
whereas I have a more broad opinion about C++, I was not trying to express it here.

> You have to  
> take into full account many factors including:
> 
> a) some maintainers dislike for C++ that may reduce their contributions

Are you sure no maintainer dislike C? 

> c) the danger of unnecessary complex stuff creeping in if there is
> insufficient control and code review.

We already have unnecessary complex stuff, which is poorly documented in sources,
and not documented in any lecture courses or books. Like, exceptions and cleanups.

> b) some maintainers who simply don't care to mess with another language
> 
> d) the transition costs are non-negligible

You might want to note that the ongoing cost of using improper tools are not
zero, either.

> 
> e) the increased commplexity of the environment necessary to build
> GDB. Speaking a moment from AdaCore's point of view as an example,
> this would mean we had to build and maintain C++ compilers on dozens
> of configurations. We can probably do this, but it is not zero work,
> and I have no idea how other organizations would be affected.
> 
> f) the danger that points a) through e) together might lead to a
> divergence in the development path.

This is strong statement. Do you have the evidence that such a divergence
will happen among those folks who *actively* contribute things?

> My inclination is that the minuses outweigh the pluses.
> 
> To make this point clearer, suppose I suggested we recode the
> whole of GDB in Ada. From purely a language point of view, the
> technical arguments in favor of such a recoding would be very
> strong, and indeed I would be happy to argue and demonstrate
> that from purely a language point of view, this would be a
> better choice than C++.
> 
> However, everyone (including me) would agree that in this case
> a) through f) would outweigh any technical langauge advantage,
> so much so that the proposal would not be considered seriously
> at all.

Well, there are obvious *practical* differences between C++ and Ada,
which makes C++ more viable for any codebase presently in C.

> 
> Obviously the transition from C to C++ would be easier, but I
> see too much of the argument focused on the language advantages,
> and not enough on the balance of the negative and positive points.

I think that it's pretty much impossible to get accurate estimate of
benefit/cost ratio, especially when benefit includes such abstract
things as developer's productivity, and elimination of the current wards,
especially wards for potential new contributors. 

I think that in this case, the most important argument is that GDB already
uses most of the features C++ has to offer -- except in non-standard and
undocumented way. Switch to C++ will make that better. The only price to
pay is requiring C++ compiler -- and given that the GNU project makes GCC,
I just don't see the issue.

- Volodya