[PATCH 0/7] Language Class Hierarchy Conversion (Prt 3)
Andrew Burgess
andrew.burgess@embecosm.com
Fri Jun 19 16:18:22 GMT 2020
* Tom Tromey <tom@tromey.com> [2020-06-19 08:25:56 -0600]:
> >>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
>
> Andrew> In this third patch set I convert the last remaining function pointers
> Andrew> in the language_base structure into member function in language_defn.
>
> Andrew> There wasn't anything particularaly tricky in this batch.
>
> I skimmed these and it all seems fine to me.
>
> Andrew> After this set my plans are (in no particular order):
>
> Andrew> - Convert at least some of the data members in language_base into
> Andrew> member function in language_defn.
>
> Andrew> - Move some of the language classes into header files so that member
> Andrew> functions can be defined in different .c files. This will allow
> Andrew> me to remove most of the member functions that currently just
> Andrew> redirect to a function in another file.
>
> Andrew> - Possibly restructure the language class hierarchy to increase the
> Andrew> amount of sharing that exists between similar languages.
>
> Andrew> - Make more of the per-language helper functions private functions
> Andrew> within the language classes.
>
> Andrew> Thoughts, feedback, or ideas always welcome.
>
> I wouldn't mind getting rid of the LA_* macros. Especially after this
> series, I don't think they add much.
In many cases they hide an access of current_language. In my mind,
ideally, I like to use current_language less. So, when you parse an
expression at the prompt at some point this would trigger some kind of
current_language->entry_point_function (....), but after that we
should remain within the language class as much as possible to parse
the expression, and not be using current_language at all.
But yes, I'd also like to see those macros gone :)
Thanks,
Andrew
More information about the Gdb-patches
mailing list