On Thu, Mar 29, 2018 at 8:01 PM, Mikhail Maltsev <malts...@gmail.com> wrote: > On Wed, Mar 28, 2018 at 11:15 PM, Katsunori Kumatani > <katsunori.kumat...@gmail.com> wrote: >> >> 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. > > I think this would be pretty straightforward: you will need a single plugin > event, which would allow you to provide your own instance of a class derived > from lang_hooks. You could then inherit a new class from the lang_hooks > class in the frontend and override any of its virtual methods. > > -- > Regards, > Mikhail Maltsev
But the point is that, when I first started using this "trick" with overriding hooks, there was no such functionality. I'm not saying that adding it is a bad thing! I'm only saying that, in this context, C hooks are easier to change without having to account for special plugin code (which did not exist). For example what if someone else comes up with another idea like that (but which has no workaround yet), but he can't do it anymore and has to request a change? Most people would probably give up on their plugin ideas at this point. I mean, most hooks don't even have a "this" pointer or object, I don't see why making them virtual would be better anyway, especially since it's *only one* object we're talking about? (one global variable). Function pointers obviously bloat things up if there's a lot of instances of the class/struct, but this is not the case, so they make more sense in this case than virtual methods IMO.
