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, 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-27 09:44:41 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!cyclone.bc.net!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" 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: Date: Tue, 27 Jan 2004 12:30:19 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1075224567 198.96.223.163 (Tue, 27 Jan 2004 12:29:27 EST) NNTP-Posting-Date: Tue, 27 Jan 2004 12:29:27 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:4914 Date: 2004-01-27T12:30:19-05:00 List-Id: Robert I. Eachus wrote: > 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.) It could be argued that MDC, lurkers and I are not getting our 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. The "Ada phylosophy" works until you start interfacing to many foreign components (normally C ones) that cannot be relied upon to be the same. You cannot even rely on the same API to be available, in some cases. This is where things get real ugly. The practical side of many bindings, requires me to deal with portability issues in a "C wrapper". This may not always be entirely possible to avoid because of C macros, but I would like to put more code into Ada than into C. But I can't, because Ada cannot deal with the portability issues. That is, unless I resort to processes outside of the language (like gnatprep and code generation). I would just like people to look at some of the "practical" issues without resorting to quoting "ivory tower" notions. Again, all of this would be _optional_ anyway. The military can outlaw it for all I care, but for general purpose computing, it needs to be addressed. > 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. I am not against any of these techniques. What I am against is the notion that "no, we don't do it that way because it might get abused". There is a need for it in the GP case, perhaps not in the military and embedded case. But if you're only going to do the later, than why add an Annex to deal with COBOL interfaces and features? > 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. Point to some major open sourced work, where it can be compiled and installed on Win32, Linux and many flavours of *NIX, and I might believe this. Why is it that large portions of Florist is generated code? I know that C macros demand this, but what about the API issues? This says preprocessing all over it. > 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. The military can make its own rules and enforce them. But again, *sigh*, in the general purpose world, things need to be a bit more flexible. > 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. If you are binding to an API that returns a structure, and on one platform you get 3 members back, and on another you get 5, then just how is any Ada construct going to address this? What if the order of member placement is different? These are the kind of portability issues that Ada programmers must wrestle with when binding to existing code. > 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. Again, you look at the simple cases where everything is the same. When dealing with portability issues, you are looking at representation issues where the interfaces are DIFFERENT. > 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. Your examples _are_ uninteresting. The interesting ones are the ones that differ according to platform, platform version, and the choice of library(ies) used. -- Warren W. Gay VE3WWG http://ve3wwg.tk