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