From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f34f1a1939dc0c40 X-Google-Attributes: gid103376,public From: Simon Brady Subject: Re: conditional compilation Date: 2000/08/02 Message-ID: <398749EF.15829554@below.for.email.address>#1/1 X-Deja-AN: 653393242 Cache-Post-Path: the-rowan.albatross.co.nz!sbrady@kakapo.otago.ac.nz Content-Transfer-Encoding: 7bit References: <87d7jvp3qq.fsf@chiark.greenend.org.uk> <39857E5F.33C40014@acm.com> <3985FB16.82D140BB@below.for.email.address> <8m6log$r3a$1@nnrp1.deja.com> X-Original-NNTP-Posting-Host: ns.albatross.co.nz X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Abuse-Info: Otherwise we will be unable to process your complaint properly X-Complaints-To: abuse@GigaNews.Com X-Trace: sv2-FL9I2NIE9+81Y61RJtmcPbKGx8dkDIGT/H6J3hcS0i8+qt9YHFm9TfqmP+/0Y90rjBHB6OyNH939CcH!dCWEkLJ782TYxaz8eztyvYYm Organization: University of Otago CS Dept X-Original-Trace: 2 Aug 2000 10:06:40 +1200, ns.albatross.co.nz X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) MIME-Version: 1.0 NNTP-Posting-Date: Tue, 01 Aug 2000 17:53:26 CDT Newsgroups: comp.lang.ada Date: 2000-08-02T00:00:00+00:00 List-Id: 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