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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38159b1b5557a2e7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-21 04:39:25 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news.he.net!newsfeed1.easynews.com!easynews.com!easynews!elnk-pas-nf1!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread3.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <400E72F9.8060501@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) References: <49cbf610.0401170627.79c3dfe5@posting.google.com> <400A9B48.3060100@noplace.com> <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 21 Jan 2004 12:39:24 GMT NNTP-Posting-Host: 209.165.24.48 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.atl.earthlink.net 1074688764 209.165.24.48 (Wed, 21 Jan 2004 04:39:24 PST) NNTP-Posting-Date: Wed, 21 Jan 2004 04:39:24 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:4598 Date: 2004-01-21T12:39:24+00:00 List-Id: While I find preprocessors distasteful and can see how they can become an unholy mess (look at some of that "Portable C" code to which you refer! :-) I'm afraid I'd have to agree to some extent. Ada ought to have some sort of answer for how to deal with maintaining a single body of code that has to compile for more than one environment. Even if you have the same target hardware and two different compilers (even from the same manufacturer sometimes!) you can have statements that will compile on one but not on the other. Isolation with separate bodies is sometimes difficult to do and always complicates the build process. Some form of conditional compilation would make the job easier. Naturally that has risks and can lead to all sorts of abuse. I'm not sure there is a good answer, but Ada ought to try to address it somehow. Eventually, developers need some scheme for how to deal with implementation differences and platform differences. To the extent that it can be handled via isolation in "standard" & "portable" interfaces, this is a good thing. But we've seen reluctance to do so for a variety of reasons, not the least of which is the time & expense to get those interfaces specified & implemented by the vendors. Even then, you'll have differences that can't be cleanly dealt with that still give full access to the underlying features of an OS or implementation. I'm not smart enough to figure out if there is a better answer than conditional compilation, so I'd have to agree that some sort of standard method of getting conditional compilation or preprocessing would be a good thing. MDC Warren W. Gay VE3WWG wrote: > > (I'll probably take some heat for this but..) > > In my opinion, the preprocessing of C code has made C the clear > winner (and now C++) for portability. Examples of code that > compiles and runs on the ancient Atari, BeOS, UNIX and Windows > etc are not hard to find. Unless the Ada code is pretty > much disconnected from the operating system, you won't find > the same level of portability. > > Granted preprocessing results in ugly code. But it is > pretty clear that developers prefer to maintain one > source module, rather than trying to keep 10+ parallel modules > synchronized (for each supported platform). > It is certainly my preference to centralize maintenance. > Any time you can centralize the control of something, > maintenance becomes cleaner, and is forced > to be consistent (much like database normalization). > > gnatprep obviously helps to address this issue for the "gnat > world". But IMHO Ada could be well served if there was a standard > for an Ada preprocessors. Its use of course would be optional > (for the purests and those situations where it is not needed), > but a standard would make Ada code more easily portable. > > Failing that, everyone must bake their own solution to this > problem. Many maintain that by centralizing problem code into > separate libraries works well enough. But this does not help > in the cases where a product can be compiled with different > options turned on or not (say from a Makefile). In other cases, > it may mean enhancements involve maintenance of several parallel > modules, instead of one centralized location. > > I havn't checked to see if any current discussions are > taking place about the possibility of standardizing a > preprocessor. But if were to guess, it has been discussed > and summarily dismissed on religious grounds ;-) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ======================================================================