The heart of GCC should remain pure C as far as possible, for the very same reason the Linux kernel is only in C. Deviate from this, and in a few years we will end up with Java as the programming language of GCC.
It is the duty of the steering community and our leaders in GCC to be very conservative in this regard. Please I don't want to oppose someone’s proposal, I want the people to understand reason of being conservative in this regard, because they will end up being the leaders of GCC in the following generations. GCC steering community I count on you and speaking behalf other developers to keep GCC as close to C as possible for at least the next 1000 years. On Thu, Mar 29, 2018 at 12:15 AM, Katsunori Kumatani <katsunori.kumat...@gmail.com> wrote: > Please don't change the lang_hooks into virtual methods. Speaking from a > plugin development viewpoint, C hooks are very easy to override > individually, without having to change the entire object or create a new > one. > > I realize that it's not the intended use for the hooks, and not why they > were created. But they enable plugins to do a whole lot more, despite the > limited plugin event callbacks already present (*especially* the targetm > hooks!). > > For example, I wanted to add some plugin processing (actually a top-level > asm statement) at the end of a translation unit (with gathered data) to add > some special symbols / GAS directives (not instructions). But there's no > "normal" plugin event for this. > > So instead I simply saved the original lang_hooks.parse_file hook (pointer), > overrode the hook with the plugin's, which calls the original first and then > does whatever plugin does. And it works fine. This kind of thing wouldn't be > easily changed with virtual methods I believe. > > Once again, I realize that was not the intended use for hooks, but it's a > nice side effect and IMO should be kept. > > Plugins suffer a lot from the "chicken and egg" problem (nobody wants to add > events that would not be needed, but nobody codes plugins without enough > events) and hooks kind of solve a lot of it, so that's a good thing > (especially targetm, more so than lang_hooks). > > I mean, if you had to first suggest an event and *hope* it gets added before > even starting your plugin (otherwise it would be a waste of time), you'd > just give up. Or at least, the majority would. At least with hooks, nobody > needs to add anything for plugins, since you can override the C hooks > directly from the plugin (while maintaining a chain for the old one).
