Thu, 12 Nov 1998 08:50:10 +0200
>From: "W. Wesley Groleau x4923" <[log in to unmask]>
>> 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?
No, of course not.
>Have you ever seen an Ada compiler that's less than ten years old with Integer
>less than 32 bits?
Yes, for embedded applications, eg. 1750A processors.
>How many applications can you name that depend on
>exponents or string indices larger than 65 thousand?
The limit is 32 thousand (signed 16 bits), but I agree, applications
are unlikely to use predefined type String for larger values.
>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
I've seen some problems were predefined Integer was used for components
of records with representation clauses that assumed 16-bit integers
which of course failed to port to a system with 32-bit integers. Why
was predefined Integer used? Believe it or not, the developers claimed
that the compiler produced better code than for a user-defined type
with the same range. Weird.
One area of the Ada 95 standard that uses predefined Integer in a way
that I think may well lead to portability problems for embedded systems
is in Ada.Real_Time, in the arithmetic operations that compute with
Time_Span and Integer. For quite realistic real-time clock resolutions,
the range of times that can be handled with a 16-bit Integer is very
Nevertheless, for portability I would pick Ada over C/C++ or Java.
[log in to unmask] Space Systems Finland Ltd.
Phone: +358 9 61 328 625 Kappelitie 6
Secretary: 61 328 600 FIN-02200 Espoo
Fax: 61 328 699 Finland
Time Zone: EET = GMT + 2