Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Fri, Jul 19, 2019 at 10:55:59AM +0100, Richard Sandiford wrote: >> Jozef Lawrynowicz <joze...@mittosystems.com> writes: >> > Is the downside of this macro implementation compared to a DEFHOOKPOD >> > mainly >> > just the maintainability/readability of the added code? >> >> Macros are essentially the "old way" and target hooks the "new way". >> The decision was made a long time ago to move away from macros where >> possible. TBH I no longer remember the reasons clearly, but I think >> it was partly to avoid including so much target stuff in non-target >> files, and partly in the hope that we might one day support multiple >> targets in a single build. Years later, we're not much closer to the >> latter and I'm not sure it's a realistic goal. > > Macros also are hard to use: they do not follow the normal language rules, > they just do text replacement (and C macros are terribly weak, at that). > Some of this is made better by conventions like "always put all uses of > macro parameters in parentheses", but that itself is an extra mental load > to remember. > >> That said, there are some macros that are too compile-time sensitive >> to be hooks or variables. BITS_PER_UNIT is the most obvious example. > > Maybe C++ can help here? Or maybe we can declare some hooks as inline > functions somehow?
FWIW, I have a WIP patch that uses C++ here. I expect people will hate it :-) Richard