This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Move GDB to C++ ?


On Monday 14 July 2008 20:03:05 Robert Dewar wrote:
> Vladimir Prus wrote:
> 
> >> a) some maintainers dislike for C++ that may reduce their contributions
> > 
> > Are you sure no maintainer dislike C? 
> 
> I never indicated an opinion on this, let alone that I was sure,
> indeed this is discussable.
> > 
> >> 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.
> 
> Right, but I still think it's a danger that should be discussed
>
> >> 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.
> 
> Well of course not everyone agrees with the "improper" here, but
> for sure discussion of ongoing and long term advantages is
> appropriate
> 
> >> 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?
> 
> It's obviously a danger, if you think the danger is minimal, fine,
> but it is important to make sure that there is a sufficient
> consensus among all those involved to avoid this.
> 
> > 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. 
> 
> Not sure what "wards" means here (warts?) but anyway, in the absence
> of some kind of reasonable estimate of bvenefit/cost ratio, there is
> a strong argument for the status quo I would think, so I think it is
> necessary to try to make this estimate, accurate is too strong, but
> reasonable is reasonable :-)

I think you're falling into a trap common for planning large transitions.
It seems reasonable to prepare of list of points, and compare alternatives
on each point. However, I never saw this work, because even if you and I
agree on one specific point, there's slim chance that 10 different people
will all agree on that single point. And if there are 10 different points
to discuss (with varying importance) and 20 different people (with varying 
degree of involvement, and varying backgrounds, and varying opinions about
the importance of the points), how do you come with a clear "yes"/"no" result?

Most transitions I saw involved:
1. A few folks pushing for specific solution that improves on the current
status quo.
2. Other folks expressing opinions like "we absolutely need XXX"

So, here, what are your most important concerns? Do you see those concerns can
be mitigated, or not?

> > 
> > 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.
> 
> Proper documentation is always a good thing, so to the extent that the
> current issues are to do with undocumented stuff, I would fix them by
> providinng the documentation before deciding that switching to another
> language will magically fix the failure to document things well.

The problem is the book named "The C++ Programming Language" went through at 
least 3 revisions, presumably with extra help of professional editors. Do we want
to beat that? And why newcomers who already read this book should read the
documentation for our non-standard mechanisms.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]