In article <39B5AF88.CCAC330A@uow.edu.au>,
Andrew Morton <andrewm@uow.edu.au> wrote:
>
>But still, doing the conditional compilation at compile-time rather than
>preprocessing-time is so *nice* that if you don't have too many literal
>strings floating about it may be justifiable.
>
>In cs89x0.c you reduce the object size by 1.5k by setting DEBUGGING to
>literal zero - no #ifdefs in sight.
Yes. The i387.c thing uses this too to make for much more readable code
(instead of using CONFIG_MATH_EMULATION etc, it uses it's own #defines
and variables, and lets the compiler sort it all out).
It definitely has many advantages, especially in that it allows real C
flow and thus much nicer syntax.
And a lot of code becomes much nicer if instead of having
#ifdef CONFIG_FOO
do_this_thing();
#endif
you have an unconditional
do_this_thing();
and you just define that to possibly end up being zero code for the
cases you don't care about - even if you use the pre-processor for that
phase. I basically always prefer that kind of syntax.
At the same time, there is no question that true #ifdef's have
advantages, even outside the issue of gcc's inability to forget literal
strings. They are often required for data structures in general: C does
not have "conditional data structures". Certain fields just do not
exist when SMP is disabled, for example. And we don't _want_ them to
exist, because they bloat out data structures that we're trying to keep
reasonably small.
So I disagree with the notion that we should try to avoid using #ifdefs
etc completely. But I agree that in many cases you can _locally_ try to
avoid it, resulting in nicer and more flexible code that also has the
advantage of making sure it can be parsed regardless of what the
configuration is.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:26 EST