This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Will therefore GDB utilize C++ or not?
On Mon, 09 Apr 2012 21:48:57 +0200, Pedro Alves wrote:
> Symbol/types even are long lived objects, it's not common at all to need to
> worry about leaks (RAII/exceptions) here.
They are and they should not be, this is what archer-jankratochvil-vla with
dynamic types is there for and which are not well maintainable without C++.
There was Tom's reference counting implementation which I found fragile
+ complicated so I wrote a custom garbage collector
[patch 0/8] Types Garbage Collector (for VLA+Python)
http://sourceware.org/ml/gdb-patches/2009-05/msg00543.html
but it was sure also a wheel reinvention, with RAII it would be all easier
(sure not automagical but some parts of reference counting done
automatically).
> On 04/09/2012 08:05 PM, Jan Kratochvil wrote:
> > Not just that one, std::string vs. cleanups vs. exceptions are even more
> > wanted (by me); just static typing (probably) cannot be done without C++,
> > the other parts are still being fixed up without C++.
>
> Sure, there will always be bugs. C++ doesn't magically make all bugs go away.
> Even RAII is not _that_ different from cleanups.
It is very different, for the very common std::string one does not even have
to start thinking about any cleanups.
If GDB should stay with C then OK (although FYI I am not so in favor of it).
But then it should be real C - therefore without GDB cleanups, without GDB
TRY_CATCH etc. etc., proper C code returning error codes from each function
and each caller checking it and doing all the local cleanups by hand.
I do not know any larger project in C with proper error checking, there are:
* Linux kernel lacks proper error reporting, common unclear EPERM from ptrace
for 100+ different reasons is a great illustration. At most it uses printk,
not too good and even reusable for GDB.
* GCC uses an extra garbage collector with terrible markers in C code, that
is also not a good example to follow. I do not remember / know how they
resolve error reporting / exceptions in GCC.
* There sure are more larger projects in plain C, but which ones?
Daniel's idea of having two - light (C, separate code) + heavy (C++, GDB
sharing code) - gdbservers I had on my mind myself before his post.
Thanks,
Jan