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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!philmtl!philabs!linus!munck From: munck@linus.UUCP (Robert Munck) Newsgroups: comp.lang.ada Subject: Re: limitations on optimizers for conditional compilation Message-ID: <82976@linus.UUCP> Date: 11 Dec 89 20:10:06 GMT References: <8912110202.AA11909@mbunix.mitre.org> Reply-To: munck@chance.UUCP (Robert Munck) Organization: MITRE-McLean Software Engineering Laboratory List-Id: In article <8912110202.AA11909@mbunix.mitre.org> emery@MBUNIX.MITRE.ORG (Emery) writes: >... (discusses conditional compiliation of executable code)... > >Where this approach fails, though, is in non-statements such as type >declarations. It would be nice to have support for this: > record >#ifdef VAX > y : float_64; >#elsif IBM_PC_WITH_8087 > y : IEEE_float; >#endif > >... but I also suspect that it wouldn't take much to come up >with type definitions where a variant record approach wouldn't work. I'm not so sure about this anymore. I have a feeling that "type definitions where a variant record approach wouldn't work" may well be the equivalent of "programs where structured coding doesn't work." We oldtimers are all used to playing fast and loose with the source text with preprocessor statements, including such horrors as "manufacturing" keywords from conditionals and compile-time variables. Maybe, just maybe, that isn't such a good idea, and the good software engineering practice would be to stick to the language definition, variant records and all. I have only one data-point, a small OS with a fair number of "sysgen" variables and choices. I found it fairly easy and "satisfactory to my esthetic sense" to do everything entirely within the language.