Is it generally encouraged or discouraged to create a pre-processor macro in C, that facilitates the creation of many functions with the same signature (differing only in name). For instance, instead of:
obj *car(const obj *args, obj **envp, GarbageCollector *gc) { ... }
obj *cdr(const obj *args, obj **envp, GarbageCollector *gc) { ... }
obj *cons(const obj *args, obj **envp, GarbageCollector *gc) { ... }
...
you could do:
#define DEF_PRIMITIVE(name) obj *name(const obj *args, obj **envp, GarbageCollector *gc)
DEF_PRIMITIVE(car) { ... }
DEF_PRIMITIVE(cdr) { ... }
DEF_PRIMITIVE(cons) { ... }
...
the point being to reduce tedious repetition in the code. I can see several arguments on either side for whether this is a good idea.
Reasons to do this
- Increase in code readibility
- Increased ease of changing the signature. i.e. if the signature of all these functions need to be changed, it need only be done in one place. (In my case, I had to change all of the signatures once and it was a real pain)
- Potential reduction of errors and time spent when creating new functions of this type.
Reasons not to do this
- It obscures the arguments to the functions, making it unclear to someone unfamiliar with the code what the arguments to the function are (if they happen not to see or find the macro definition).
- Certain IDEs have trouble with these definitions inhibiting the IDE's ability to refactor or reason about usage of the function.
- Extensive use of macros is generally discouraged in C programs, and errors in them generally lead to hard to identify bugs.