Messages in this thread |  | | From | (Linus Torvalds) | Date | 6 Sep 2000 10:10:09 -0700 |
| |
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/
|  |