This is the mail archive of the 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 Friday 01 August 2008 17:18:26 Eli Zaretskii wrote:
> > From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= <>
> > Date: Fri, 1 Aug 2008 16:06:14 +0200
> > 
> > I can think of a few directions that might be interesting:
> > 
> >   (1) a working, full featured MI interface,
> >   (2) integrated scripting,
> >   (3) performance improvements.
> >   (4) gdb-as-a-library.
> > 
> > The question whether they are hard "because it's C" is open:
> > You will say no, I say yes, simply because high level restructuring
> > is more painful in C than in reasonably C++.
> Don't worry about what I'm going to say.  Just give specific arguments
> why C++ will enable these directions significantly better than C.  If
> you do that, you might be surprised by what I will have to say.

The reasons are the basically the same as the one I gave in other
parts of this thread. Assuming a rational approach to the type
and way C++ features are used we have:

1. Using C++ reduces source code size typically by a factor of 2 or
more _while improving readability_ as the the code that vanishes from
the sources is boiler plate code for, say, manipulating containers, or 
cleaning up within a function. The remaining "essence" is easier
to browse, faster to scan by humans and easier to refactor.

2. C++ helps to pick the right containers and algorithms at the
beginning, and makes it easier to switch later in case of errors
as different types of containers and algorithms often offer similar
interfaces - despite of different implementations and performance
characteristics. This is in stark contrast with C where container
access and manipulation is typically "manually" inlined on the
user side (up to the degree where "containers" as such do not
even exist but rather are conventions like  "start at a pointer, and
end at the next embedded end-marker", or "this item, and whatever
is linked from its 'next' pointer"). Refactoring such code, say, 
replacing the container with some other with different performance
characteristics, typically involves a complete rewrite of the user
code, and is far more error prone as "sticking to the conventions"
more often than not cannot be checked by the compiler itself.

The ability to refactor easily will certainly help with gdb performance.
Also, it helps when creating "higher level functionality", when it is
not clear on the outset how a good solution would look like. E.g.
MI currently is a mess (sorry for being blut again...). Incomplete, 
inconsistent, and misleadingly documented. Incidentally, C++ can
help to create more uniform internal interfaces as _using_ such
is much more common than the "inline-everything-manually-and-
needed"-style approach of C.

n. On top of that: C++ does not hurt. C code can stay (sometimes
with minor adjustments) if needed and none of the advantages
cited above are wanted. Also, C++ _is_ widely available, and also
g++ 2.95.3 would fit the bill for what I think gdb needs.

I just notice I wrote something like that already, so maybe I'd better
stop. As far as I can tell, all arguments have been on the table for
a few times now. The strongest argument against that I saw was
Mark's fear that using C++ for future gdb releases might hamper
his ability to use a seven year old compiler for non-GNU-base 
operating systems, and that fear is very likely to be unfounded.
Of course I can't tell for sure since he did not point to any specific 
problem. I doubt there is any for our (my?) envisioned usage pattern.
The fear of "inevitable smart pointer invasion" is certainly not 


PS: I am also somewhat tired of this discussion now. I suppose I'll 
try again in a few years...

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