Move GDB to C++ ?

Mark Kettenis
Wed Jul 30 12:35:00 GMT 2008

> From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= <>
> Date: Wed, 30 Jul 2008 13:56:56 +0200
> On Tuesday 29 July 2008 20:08:42 Andrew Cagney wrote:
> > The question I'm asking here is are we focusing on C++ as a solution, 
> > and mistakenly trying to rely on its features as a solution, when we 
> > should instead be first focusing on the design, what ever the 
> > implementation language?
> I've seen a few code reviews on gdb-patches pointing out improper
> (like missing) use, of, say, 'xfree'. Getting these right seems 
> straightforward from a conceptional point of view, yet humans
> err, and there's a lot of time spent in creating such code and
> reviewing it. Also, it adds a certain level of "line noise" to the code
> making it at least for the casual reader of the code hard to distinguish
> what the actual meaning of a chunk of code is, and what belongs
> to the "house keeping". 
> This is one of the things C++ or  (- better also in my opinion -)
> "C with classes" can solve. Destructors are friends. So, yes,
> C++ can help to solve proble like the problem of limited developer
> resources.

Dream on.  How is xfree() different from delete?  Oh you have smart
pointers.  You'd better make sure you use them consistently in your
code, otherwise you end up getting yourself in the confused state
where you can't even tell whether there's a missing delete or not.
And then you decide to use a third-party C++ library.  Now you're
almost certainly using your smart pointer inconsistently, or worse,
have smart pointers with different semantics.

Yes, C++ has some features that make memory management easier in
theory.  But they're not the magic bullet that their proponents claim
them to be.

More information about the Gdb mailing list