comp.lang.ada
 help / color / mirror / Atom feed
From: Corey Ashford <yeroca@rocketmail.com>
Subject: Re: Code portability question
Date: 1999/01/23
Date: 1999-01-23T00:00:00+00:00	[thread overview]
Message-ID: <36A9849C.A9FE01E4@rocketmail.com> (raw)
In-Reply-To: 36A94B78.963F3215@wvu.edu

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.




  parent reply	other threads:[~1999-01-23  0:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-22  0:00 Code portability question Mike Werner
1999-01-23  0:00 ` bill_1
1999-01-24  0:00   ` Mike Werner
1999-01-23  0:00 ` Corey Ashford [this message]
1999-01-23  0:00   ` bill_1
1999-01-24  0:00   ` Mike Werner
1999-01-24  0:00     ` Corey Ashford
1999-01-25  0:00       ` robert_dewar
1999-01-25  0:00         ` Corey Ashford
1999-01-25  0:00           ` dewar
1999-01-23  0:00 ` Tucker Taft
1999-01-24  0:00   ` Mike Werner
1999-01-31  0:00     ` Nick Roberts
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox