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 Wed, 18 Apr 2012 16:10:58 +0200, Pedro Alves wrote:
> On 04/16/2012 07:54 AM, Jan Kratochvil wrote:
> > 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++.
>
> I don't even know how to begin to respond to that. :-) The symbols side is perhaps
> the part of a debugger that needs the most care about memory, and where you'll
> most likely to see the need for POD types, and lower level handling of
> memory, like the bcache.
This is the current wrong approach where
(a) CUs are expanded fully, not just the one or few symbols one started
expanding that CU for.
(b) CUs are expanded needlessly, such as during <tab>-expansion, there are
more cases I did not analyze.
And then with 99% of symbols not needed at all one tries to optimize every bit
out of each symbol to make the 100% total size bearable... Just because
everything is statically accessed and the expansion cannot be easily done
on-demand when one accesses the fields by using getters everywhere.
I can't believe we do not agree on such basic way forward.
As one of the many examples the current main_type is unbelievable, I would not
think it is possible to create something so bizarre, it could be sure fixed by
redesigning it even in C (one big union with all fields specific per type and
not just generic fields each overloaded differently for each type). But then
we would end up with GTK - it has the right design but it is still C++-in-C,
I hope everyone agrees GTK is wrong.
Regards,
Jan