Re: conditional compilation

[Simon Brady <see@below.for.email.address>]

Ted Dennison wrote:
> 
> I've often had to figure out someone else's large C program that was
> chock full of target-dependent #ifdef's. Its a *nightmare*. Often times
> you have to dig deep into the bowels of an even more complicated
> makefile to even figure out which conditional branches your compilation
> is using.

Been there, done that... I think the literate programming crowd offer a
useful insight here: programs aren't the same thing as representations
of programs, and what the compiler sees isn't necessarily what the
programmer should see. C source loaded up with #ifdefs isn't really C
source - it's a template for generating C source. Sometimes the
programmer wants to view the template (for a configuration-management
perspective), other times she's interested in a particular instance of
it.

Imagine an editor integrated with the C preprocessor that supported such
multiple views (I guess it would also have to grok makefiles and other
source-molesting tools like lex and yacc). Ideally you'd never need to
see a preprocessor directive except when you were in "configuration
managment mode" - you could switch between targets, debug/release views
or whatever, and always be dealing with a direct representation of that
particular instance of your program. This seems quite doable, and could
alleviate many of the problems you've described. Sure, no tool can
outwit human perversity, but something that reduced my grappling with
the preprocessor by even 50% would be a good thing.

(Btw, Ch. 18 of Stroustrup's "Design and Evolution of C++" presents a
succinct discussion of why the C preprocessor is evil, yet has been so
successful and will be so hard to banish:

   Cpp does [its] tasks pretty badly, mostly by indirect means, but
   cheaply and often adequately. Most important, Cpp is available
   everywhere C is, and it is well known. This has often made it
   more useful than far better, but less widely available or less
   widely known, macroprocessors.     (p425)

I like Stroustrup's sensitivity to "sociological" issues - he repeatedly
makes the point that it's not enough to offer better alternatives to C's
shaky features, you also have to offer features that real-life C
programmers will want to switch to.)

> The Ada approach is supposed to be that you have different source files
> for different targets, and use your build tools to choose between them.
> From a maintanence standpoint I like that idea a whole lot better. But
> it requires that the program be organized ahead of time for this

A fair comment, but allow me to play devil's advocate here (to
paraphrase Martin Condic, just because I've found conditional
compilation useful I don't necessarily like it). The above approach may
be clean and effective for multi-targeting. However, where I most use
conditional compilation in my C/C++ work is for inline debugging code (I
admit to being heavily influenced by Steve Macguire's "Writing Solid
Code" here). This is stuff I want tightly bound to the code it supports,
both in terms of sharing the same lexical scope and (more importantly)
of reading sequentially so maintainers see it as an integral part of the
routine. Again, it's that template vs. source distinction - the approach
I'm describing involves delivering two products (program and integrated
self-test), which sometimes I want to view together and sometimes I
don't.

As Martin has noted, pragma Debug achieves most of this, with the
exception of debug-only declarations (which can be useful, although
perhaps not useful enough to justify messing with the language). And the
mythical environment I've described above could work with Ada pragmas as
easily as C #ifdefs (was such a capability part of the APSE dream of the
80s?). But, just for discussion's sake, is there a better "Ada way" to
achieve what I'm describing? Or is it so rooted in the existence of Cpp
as to be inherently opposed to the Ada spirit?

OK, enough speculation for one day - time to go do some work (yawn).

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org