[ *ON* topic thread ] > Your patch is purely about enforcing arbitrary syntax rules and in the > process adding redundant code that obscures what is going on. For > example consider: > > ... > ARM11_HANDLER(bar), > GENERIC_ARM_HANDLER(dog), > ARM11_HANDLER(moo), > ...
See, I count those *_HANDLER() macros as obscurant; and since they're not necessary, also as redundant. They're not at the "#define TWO 2" level, true. And there have been a few cases where similar CPP tricks have IMO been the right thing to do ... *NOT* in this case though. I would also call expecting such macros to be *used* as enforcing "arbitrary syntax rules". One difference: the rest of the project does NOT use such macros. So in the context of OpenOCD, those particular macros are an incomplete subset of an exotic model. (Incomplete since there are no other core handler macros...) Just using unadorned C struct initializer syntax is the normal policy, used everywhere else. > Or to take the ARM11_HANDLER example, would you quickly spot the error > if you forgot to switch arm_bar to arm11_bar when you replace the > function with a more specialized version? The compiler would have told me that arm11_bar() was defined but had no users. Or my review of the patch, pre-submission, would have noticed that it was clearly wrong. (You *DO* carefully review code before submitting or merging it, yes? Mistakes sometimes happen even with review, but that is an example of a problem that review would almost certainly catch.) > The point is, the arm11 code doesn't use macros for fun, it uses them > for clarity and to avoid trivial mistakes. And unlike the OUT_FIELD > example it uses them only where functions are impractical or > impossible. My opinion is that a general distaste for macros (or any C > code that deviates from K&R) is not a good reason to override these > design decisions. So it's a good thing that "a general distaste for macros" was NOT one of the reasons for the $SUBJECT patch. However, it's worth noting that preprocessor abuse is widely recognized to be a danger in C programs, and one that projects need to prevent. Inline functions, for one example, are type-safe and free of problems like lexical capture and multiple evaluation. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
