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? Segher
