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,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dec0a6ed5b5044de X-Google-Attributes: gid103376,public From: Corey Ashford Subject: Re: Code portability question Date: 1999/01/23 Message-ID: <36A9849C.A9FE01E4@rocketmail.com>#1/1 X-Deja-AN: 435937671 Content-Transfer-Encoding: 7bit References: <36A94B78.963F3215@wvu.edu> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Rational Software Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-01-23T00:00:00+00:00 List-Id: Mike Werner wrote: > > Hi folks. Got into an argument the other day, and am now trying to get > some more info from those more knowledgable then myself. I'm a first > year CS student, and the argument was with another student in my class. > The point of contention revolves around some code written on a PC with a > K6 as the CPU. The code needed to be mostly rewritten to compile on the > department's Unix server. The code was written and tested on the PC, > then uploaded to the Unix server. Once on the server, a compile was > attempted but failed, necessitating the rewrite. The code was not > complex - intro CS course programming not much advanced from the classic > "Hello World" type projects. As such, optimization and such is not a > factor. The class is focused on introducing programming with Ada95. > > Now, one side claims that this was necessitated by the architecture > difference, due to the K6 CPU being designed differently and handling > floats differently. The other claims that either the code was badly > written or the compiler used was faulty or ... something was broken > somewhere. > > I would appreciate any pointers as to which is correct. But please be > gentle - I'm still learning this language and if you get technical on me > I could easily get lost. It's impossible to evaluate this without seeing the example code, and getting a description of the problem that was encountered. It is possible to write Ada95 code that doesn't port easily to another machine. A simple example would be code that relies on the byte order of the machine to be big endian, and the machine to which you are porting is little endian order. In most cases, endianness won't affect you at all... it's transparent - at least until you start dealing with interfacing to hardware, networks, other computers, etc. It is possible to write code which is portable between different machines, but the coding must be done with portability in mind. The same problems can occur in C, but I think it's harder to program portably in C since the language doesn't allow you to specify the range and accuracy of types that are used. For example, in Ada, you can say something like this: type My_High_Precision_Float is digits 15; If the compiler doesn't have an underlying type that has at least that precision, it will give you a compile time error - which is a good thing! In C (or C++), you have to hope that the predefined type "double" will have sufficient precision for your application, and that if double doesn't have sufficient precision that your application will fail in a way that makes that fact obvious. Of course, you could put in runtime assertion checks in the code to test for insufficient precision, but at best you won't find out until your program actually links and runs that "double" isn't up to par. Hope this helps a bit. I'm sure others will chime in with things I haven't thought of.