[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: KNF and the C preprocessor
On Mon, 10 Dec 2012, David Young wrote:
What do people think about setting stricter guidelines for using
the C preprocessor than the guidelines from the past?
The C preprocessor MUST NOT be used for
1 In-line code: 'static inline' subroutines are virtually always better
I disagree with this one. If you tone it down to "SHOULD NOT" or
"prefer static inline functions where appropriate" then I might
agree, but MUST NOT is way too strict. Sometimes the C standard
mandates the use of macros, and I would not want to violate that
simply to comply with your "MUST NOT" requirement.
For example, the ctype(3) API must be provided by extern
functions, and may also be provided by macros; I don't see how
the macros could be replaced by static inline functions without
breaking something. The first breakage that springs to mind is
that adding parentheses around a name like (isalpha) is supposed
to prevent it from being interpreted as a macro, so you get
the function instead; but there's no analogous way to prevent
something from being interpreted as a static inline function so
you get the external function instead.
2 Configuration management: use the compiler & linker to a greater
extent than the C preprocessor to configure your program for your
execution environment, your chosen compilation options, et cetera.
Again here, MUST NOT is way too strict. While I don't like *.c
files littered with ifdefs, I think it's OK for *.c files to
contain many macro invocations, and it's OK for header files to
contain many ifdefs, but both these would be outlawed by your
"MUST NOT" requirement.
--apb (Alan Barrett)
Main Index |
Thread Index |