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,FREEMAIL_FROM, TVD_PH_BODY_ACCOUNTS_PRE 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-26 16:00:09 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!pd7cy2so!shaw.ca!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 26 Jan 2004 18:00:03 -0600 Date: Mon, 26 Jan 2004 19:00:02 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor References: <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <4011127C.4030801@noplace.com> <101377e54car5cc@corp.supernews.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-XBQvNiQAReK1ilnLCfzHsYzaQLeUIHUOJRW/IUw2uKLO5yuIFM9Gc9XrAh4odmqHlIAA1f7Lt27YsAj!HDYtk3WbzsGfBRe6DYJRtG2+Mgm8lN80vE6ZwmAnTykuSS6Se6PAdXHhdklCrQ== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:4852 Date: 2004-01-26T19:00:02-05:00 List-Id: Warren W. Gay VE3WWG wrote: > As said before, I prefer a portable platform neutral code > as much as the next guy. But when you start writing bindings > and such that must bind to _many_ different situations, > this simply becomes impractical. I feel here like I am being castigated for something I have never said. (No, I am not saying Warren is attacking me, just that I have the feeling that I am not getting my point across.) The problem is that there is an underlying philosophical difference, and until and unless you accept the "Ada" philosophy you will be uncomfortable programming in Ada. Once you "get it" Ada becomes as comfortable as well broken-in shoe. There are still some minor lumps and bumps--but you don't notice them. For a second assume that there are things that do require a preprocessor to do in Ada. Now look at the long debate here, from the point of view that one group uses preprocessor directives in with clauses and the public part of packages, while I argue that this is poor programming practice and that all preprocessor directives belong in unit bodies where possible, and as few such bodies as possible. And actually that IS the way I feel. With one minor exception. When you do the necessary work to collect all of the pre-processor decorated code in one spot, surprise! There isn't any left. But there is really a trick to this, and it is important to understand. In the military the problem is known as micro-management. Problems and issues should be addressed at the right level, without solutions imposed from above which may not be appropriate in a particular situation. In Ada where this often comes up is in representation clauses. You either tell the compiler to "do it right" with alignment directives, or lay things out bit-by-bit with rep clauses. If there is an implementation INdependent format you have to follow, sometimes because you are interfacing directly to some special-purpose hardware. Fine, use static layouts. But these are, by their nature not compiler dependent in any way. The hardware you interface with, or the other computer system you interface with, or whatever, specifies the layout. If some compiler can't support those rep clauses, it is not time for preprocessor directives, it is time to either fix the compiler or get a new one. The bits MUST look exactly like that, it is not an option. The second case is where you want the bits laid out a certain way for efficiency. Fine, no problem...and no rep clause required or needed. That is the compiler's job. You may use alignment clauses and specify that some components are aliased, but the compiler will take all that into account when it lays out the record. If two compilers do it differently on different hardware because, say, Integer is a different size? Not a problem. If you needed the records to be identical on different hardware, you would have specified things that way. So as far as I am concerned, the case of rep specs that compile on one compiler and not on another is almost uninteresting. If you care, it is a big problem. But it has to be fixed by fixing (or replacing) one compiler. A pre-processor CAN'T help. If you are trying to use pre-processor directives to force efficient layouts on each different platform, you are micro-managing. Let each compiler choose the layout it thinks is best. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush