Re: Will therefore GDB utilize C++ or not?

[Pedro Alves <palves@redhat.com>]

On 04/18/2012 04:15 PM, Jan Kratochvil wrote:

> 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... 


You appear to be talking again about high level design choices that really
doesn't have much to do with the language they're implemented in.

Sure, C++ would make some things easier, but it also makes
other objectives harder or impossible.  It's a compromise.

> 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 don't understand what you mean.  Certainly adding the C++ getters would be
as much work as adding C getters.  It's not like C++ writes itself.

Again, you don't have to convince me that C++ is nice.  I know it is.
I like it.  I've written C++ for years and practically nothing else.
ut I don't like the prospect of a fragmented GDB with important
parts in C and others in C++, with all the same issues you don't like in C
still in important and wide use.  I loathe the idea of someone contributing
some new code, and having to say "nice, but please rewrite it in C, because we
may need it for X".  If we stick to one language everywhere, in the net sum,
there's less to learn for new comers.

> 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.


...

-- 
Pedro Alves