TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"W. Wesley Groleau x4923" <[log in to unmask]>
Wed, 11 Nov 1998 09:58:19 -0500
text/plain (54 lines)
> Java is even more portable than Ada, becuase ....
> .... an int is 32 bits, no matter where one is
> running the program, and that a long is 64 bits no matter where, etc.

Of course.  In C, you write implementations not abstractions.  In Java, if
you use primitive types, you do the same.  (If you want to write an
abstraction in Java, you have to take all the OO baggage, whether you need
it or not.)  If you _need_ a particular implementation, you examine the
specifications of the compiler and hardware (or JVM) to identify the one
you need.  It's good that that Java and the JVM made them all the same in
this department, because many portability bugs are due to C programmers
being either too lazy or to uninformed to do that sort of study.

In Ada, you (mostly) specify abstractions (requirements) and the compiler
ensures that the implementation meets those specifications--if it can't,
it rejects the program.  (And the implementation is usually quite
efficient, even when OO features are involved.)  _IF_ there is actually an
implementation (representation) requirement, you don't have to find it in
the compiler and hardware docs--you just specify it and the compiler tells
you if it's not available.  (Not that there's anything wrong with looking
up during design whether it will be supported.)

> Yes, the size of INTEGER is platform dependent.  Although this can largely
> be worked-around by defining a MY_INTEGER of the desired size, string
> indices and exponents are a portability problem since they have to be
> based on INTEGER.

Have you ever seen an Ada compiler with Integer less than 16 bits?  Have
you ever seen an Ada compiler that's less than ten years old with Integer
less than 32 bits?  How many applications can you name that depend on
exponents or string indices larger than 65 thousand?  How many compilers
can you name that will support such an application?

If your algorithm depends on a type or object having a certain range or
size, you declare the type or object accordingly, and tell your suppliers
you can only accept compilers and hardware that will accept your
declarations.

If your algorithm doesn't _depend_ on the range or size, you still
(generally) specify an abstraction that makes sense.

In many years of programming mostly in Ada, some of it embedded/real-time,
I have never seen a portability problem due to the size or range of any
predefined type--not even in cases where we "should have" specified an
abstraction instead.

However, I _have_ seen a lot of ugly code written to workaround problems
caused by blind adherence to a religious "Thou shalt not use predefined
types."  In other words, specifying an implementation that isn't a
requirement, in the false belief that it's needed for portability.

I have fixed as many bugs by removing code that was unnecessary as I have
by adding or modifying code to comply with true requirements.

ATOM RSS1 RSS2