[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