Re: Naive question about system dependencies

[dewar@cs.nyu.edu (Robert Dewar)]

The whole idea in using separate bodies should be to completely avoid
code duplication. Only the code that is system dependent, and hence
NOT duplicated, i.e. the code that would go inside the range of an 
ifdef, should be in separate bodies, code outside the ifdef can be
shared.

This isn't possible to achieve completely in all cases, but you can come
very close by building appropriate abstractions, and if you have a decent
compiler which does inlining properly, there should be no efficienc y
loss from this kind of abstraction.

To emphasize, this is a design princinple which cannot always be met, but
far too much code is duplicated in situations where there has not been
nearly enough effort in attempting to meet this requirement.

Note that the disastrous thing about ifdefs is that it gets very hard to
even make sure that the module is free of syntax errors for all cases.

Suppose we have 20 ifdefs in one module, each with two settings. THen it
takes 1,000,000 compilations just to make sure that all possibilities
compile (and 1,000,000 careful test runs to make sure they all work).

If on the other hand, you have one common module, and two versions each
of 20 little modules, then you have to compile only 41 files to check
syntax correctness, and you can at least do 41 separate unit tests (the
full integration testing would of course take 1,000,000 runs, there's
no way around that, but at least it's better to have unit testing than
nothing at all).

Best of all is to try to avoid special casing in the first place. That's
cerainly the approach we try to use in GCC, where we have several hundred
possible configurations, and we are VERY unfriendly to target dependent
code, though we can't completely avoid it.

In my experience, the ability to use ifdef's is a disaster for big systems.
All to often, you get ifdefs all over the place, and the sources become
completely unmanagable.