• 16 bits available for type Integer (-2**15 .. 2**15 - 1)
• 6 decimal digits of precision available for floating-point types
• 24 bits available for fixed-point types
• 200 characters per line of source text
• 16 bits for expressions
• -86_400 .. 86_400 seconds (1 day) for the range of Duration (as specified in Ada Reference Manual [1995, §9.6])
• 20 milliseconds for Duration'Small (as specified in Ada Reference Manual [1995, §9.6])

The values for the range and accuracy of values of the predefined type Duration are the limits expressed in the Ada Reference Manual (1995, §9.6). You should not expect an implementation to provide a wider range or a finer granularity.

A standard-mode Ada character set of Latin 1 can be assumed in most cases for the contents and internal behavior of type Character and packages Character.Latin_1, Character.Handling, and Strings.Maps. However, this does not mean that the target hardware platform is capable of displaying the entire character set. You should not use a nonstandard Ada character set unless intentionally producing a nonportable user interface with a specific purpose.

------------------------------------------------------------------------

package Memory_Mapped_IO is

   -- WARNING - This package is implementation specific.

   -- It uses absolute memory addresses to interface with the I/O

   -- system. It assumes a particular printer's line length.

   -- Change memory mapping and printer details when porting.

   Printer_Line_Length : constant := 132;

   type Data is array (1 .. Printer_Line_Length) of Character;

   procedure Write_Line (Line : in     Data);

end Memory_Mapped_IO;

------------------------------------------------------------------------

with System;

with System.Storage_Elements;

package body Memory_Mapped_IO is

   -- WARNING: Implementation specific memory address



   Buffer_Address : constant System.Address

      := System.Storage_Elements.To_Address(16#200#);





   ---------------------------------------------------------------------

   procedure Write_Line (Line : in     Data) is

      Buffer : Data;

      for Buffer'Address use Buffer_Address;



   begin  -- Write_Line

       -- perform output operation through specific memory locations.

       ...

   end Write_Line;

   ---------------------------------------------------------------------

end Memory_Mapped_IO;

------------------------------------------------------------------------

package Environment is



   type Execution_Mode is (Unspecified, Interactive, Batch);



   function Execution_Argument return Execution_Mode;



   ...



end Environment;



----------------------------------------------------------------------



with Ada.Command_Line;       use Ada.Command_Line;

with Ada.Strings.Unbounded;  use Ada.Strings.Unbounded;



package body Environment is



   function Execution_Argument return Execution_Mode is



      Execution_Argument_Number : constant := 1;



      Interactive_Mode_String : constant String := "-i";

      Batch_Mode_String       : constant String := "-b";



   begin

      if Argument_Count < Execution_Argument_Number then

         return Unspecified;

      elsif To_Unbounded_String (Argument (Execution_Argument_Number)) =

               Interactive_Mode_String then

         return Interactive;

      elsif To_Unbounded_String (Argument (Execution_Argument_Number)) =

               Batch_Mode_String then

         return Batch;

      else

         return Unspecified;

      end if;

   end Execution_Argument;



end Environment;

The value returned by the function Ada.Command_Line.Argument_Count is implementation-dependent. Different operating systems follow different conventions regarding the parsing and meaning of command line parameters. To enhance your program's portability, assume the simplest case: that the external execution environment does not support passing arguments to a program.

Some operating systems are capable of acquiring and interpreting returned integer values near 0 from a function, but many others cannot. Further, many real-time, embedded systems will not be designed to terminate, so a function or a procedure having parameters with modes out or in out will be inappropriate to such applications.

This leaves procedures with in parameters. Although some operating systems can pass parameters into a program as it starts, others are not. Also, an implementation may not be able to perform type checking on such parameters even if the surrounding environment is capable of providing them.

Some implementation-dependent features may be used to achieve particular performance or efficiency objectives. Commenting these objectives ensures that the programmer can find an appropriate way to achieve them when porting to a different implementation or explicitly recognize that they cannot be achieved.

Interrupt entries are implementation-dependent features that may not be supported (e.g., VAX Ada uses pragmas to assign system traps to "normal" rendezvous). However, interrupt entries cannot be avoided in most embedded, real-time systems, and it is reasonable to assume that they are supported by an Ada implementation. The value for an interrupt is implementation-defined. Isolate it.

Ada has introduced a number of new pragmas and attributes that were not present in Ada 83 (Ada Reference Manual 1983). These new pragmas and attributes may clash with implementation-defined pragmas and attributes.

If a vendor-supplied package is provided in compilable source code form, use of the package does not make a program nonportable provided that the package does not contain any nonportable code and can be lawfully included in your program.

The Specialized Needs Annexes provide special capabilities that go beyond the core language definition. Because compilers are not required to support the special-purpose annexes, you should localize your use of these features where possible. By documenting their usage, you are leaving a record of potential porting difficulties for future programmers.

------------------------------------------------------------------------

with Ada.Integer_Text_IO;

procedure Outer is

   type Coordinates is

      record

         X : Integer := 0;

         Y : Integer := 0;

      end record;

   Outer_Point : Coordinates;

   ---------------------------------------------------------------------

   procedure Inner (Inner_Point : in out Coordinates) is

   begin

      Inner_Point.X := 5;

      -- The following line causes the output of the program to

      -- depend on the parameter passing mechanism.

      Ada.Integer_Text_IO.Put(Outer_Point.X);

   end Inner;

   ---------------------------------------------------------------------

begin  -- Outer

   Ada.Integer_Text_IO.Put(Outer_Point.X);

   Inner(Outer_Point);

   Ada.Integer_Text_IO.Put(Outer_Point.X);

end Outer;

------------------------------------------------------------------------

If the parameter passing mechanism is by copy, the results on the standard output file are:

0 0 5

If the parameter passing mechanism is by reference, the results are:

0 5 5

The following code fragment shows where there is a potential for bounded error when a procedure is called with actual parameters denoting the same object:

procedure Test_Bounded_Error (Parm_1 : in out    Integer;

                              Parm_2 : in out Integer) is

   procedure Inner (Parm : in out Integer) is

   begin

      Parm := Parm * 10;

   end Inner;

begin

   Parm_2 := 5;

   Inner (Parm_1);

end Test_Bounded_Error;

In executing the procedure Test_Bounded_Error, both Parm_1 and Parm_2 denote the object Actual_Parm. After executing the first statement, the object Actual_Parm has the value 5. When the procedure Inner is called, its formal parameter Parm denotes Actual_Parm. It cannot be determined whether it denotes the old value of Parm_1, in this case 1, or the new value, in this case 5.

Actual_Parm : Integer := 1;

. . .

Test_Bounded_Error (Actual_Parm, Actual_Parm);  -- potential bounded error

See also Guideline 8.2.7.

package Utilities is

   function Unique_ID return Integer;

end Utilities;



package body Utilities is



   ID : Integer := 0;



   function Unique_ID return Integer is

   begin

      ID := ID + 1;

      return ID;

   end Unique_ID;



end Utilities;



--------------------------------------------------------------------------------

with Ada.Text_IO;

with Utilities; use Utilities;

procedure P is

begin

   Ada.Text_IO.Put_Line (Integer'Image(Unique_ID) & Integer'Image(Unique_ID));

end P;

If the parameters to the "&" function are evaluated in textual order, the output is:

1 2

If the parameters are evaluated in the reverse order, the output is:

2 1

Use:

type    Second_Of_Day is             range 0 .. 86_400;

rather than:

type    Second_Of_Day is new Integer range 1 .. 86_400;

or:

subtype Second_Of_Day is     Integer range 1 .. 86_400;

An implementor is free to define the range of the predefined numeric types. Porting code from an implementation with greater accuracy to one of lesser accuracy is a time consuming and error-prone process. Many of the errors are not reported until run-time.

This applies to more than just numerical computation. An easy-to-overlook instance of this problem occurs if you neglect to use explicitly declared types for integer discrete ranges (array sizes, loop ranges, etc.) (see Guidelines 5.5.1 and 5.5.2). If you do not provide an explicit type when specifying index constraints and other discrete ranges, a predefined integer type is assumed.

The predefined numeric types are useful when you use them wisely. You should not use them to avoid declaring numeric types—then you lose the benefits of strong typing. When your application deals with different kinds of quantities and units, you should definitely separate them through the use of distinct numeric types. However, if you are simply counting the number of iterations in an iterative approximation algorithm, declaring a special integer type is probably overkill. The predefined exponentiation operators ** require an integer as the type of its right operand.

You should use the predefined types Natural and Positive for manipulating certain kinds of values in the predefined language environment. The types String and Wide_String use an index of type Positive. If your code indexes into a string using an incompatible integer type, you will be forced to do type conversion, reducing its readability. If you are performing operations like slices and concatenation, the subtype of your numeric array index is probably insignificant and you are better off using a predefined subtype. On the other hand, if your array represents a table (e.g., a hash table), then your index subtype is significant, and you should declare a distinct index type.

The accuracy of floating-point numbers is based on what machine numbers can be represented exactly in storage. A computational result in a register can fall between two machine numbers when the register contains more bits than storage. You can step through the machine numbers using the attributes 'Pred and 'Succ. Other attributes return values of the mantissa, exponent, radix, and other characteristics of floating- and fixed-point numbers.

You should choose the numeric type declarations to satisfy the lowest precision (smallest number of digits) that will provide the required accuracy. Careful analysis will be necessary to show that the declarations are adequate. When you move to a machine with less precision, you probably can use the same type declaration.

with Ada.Text_IO;

with Ada.Integer_Text_IO;

procedure Demo_Overflow is

-- assume the predefined type Integer has a 16-bit range

   X : Integer := 24_000;

   Y : Integer;

begin  -- Demo_Overflow

   y := (3 * X) / 4;  -- raises Constraint_Error if the machine registers used are 16-bit

  -- mathematically correct intermediate result if 32-bit registers

   Ada.Text_IO.Put ("(");

   Ada.Integer_Text_IO.Put (X);

   Ada.Text_IO.Put (" * 3 ) / 4 = ");

   Ada.Integer_Text_IO.Put (Y);

exception

   when Constraint_Error =>

      Ada.Text_IO.Put_Line ("3 * X too big for register!");

end Demo_Overflow;

abs (X - Y) <= Float_Type'Model_Small                -- (1)

abs (X - Y) <= Float_Type'Base'Model_Small           -- (2)

abs (X - Y) <= abs X * Float_Type'Model_Epsilon      -- (3)

abs (X - Y) <= abs X * Float_Type'Base'Model_Epsilon -- (4)

abs X <= Float_Type'Model_Small                      -- (1)

abs X <= Float_Type'Base'Model_Small                 -- (2)

abs X <= abs X * Float_Type'Model_Epsilon            -- (3)

abs X <= abs X * Float_Type'Base'Model_Epsilon       -- (4)

Type attributes are the primary means of symbolically accessing the implementation of the Ada numeric model. When the characteristics of the model numbers are accessed by type attributes, the source code is portable. The appropriate model numbers of any implementation will then be used by the generated code.

Although 0 is technically not a special case, it is often overlooked because it looks like the simplest and, therefore, safest case. But in reality, each time comparisons involve small values, you should evaluate the situation to determine which technique is appropriate.

-- The salary cap today is $500,000; however this can be expanded to $99,999,999.99.

type Executive_Salary is delta 0.01 digits 10 range 0 .. 500_000.00;



------------------------------------------------------------------------------

package Currency is



   type Dollars is delta 0.01 digits 12;



   type Marks   is delta 0.01 digits 12;



   type Yen     is delta 0.01 digits 12;



   function To_Dollars (M : Marks) return Dollars;

   function To_Dollars (Y : Yen)   return Dollars;



   function To_Marks (D : Dollars) return Marks;

   function To_Marks (Y : Yen)     return Marks;



   function To_Yen (D : Dollars) return Yen;

   function To_Yen (M : Marks)   return Yen;



end Currency;

You need different types for objects measured in different units. This allows the compiler to detect mismatched values in expressions. If you declare all decimal objects to be of a single type, you forego the benefits of strong typing. For example, in an application that involves several currencies, each currency should be declared as a separate type. You should provide appropriate conversions between different currencies.

You should map data with no particular unit of measure to a small set of types or a single type to avoid the explosion of conversions between numeric types.

Separate the range requirement on a decimal type from its precision, i.e., the number of significant digits required. From the point of view of planning for change and ease of maintenance, you can use the digit's value to accommodate future growth in the values to be stored in objects of the type. For example, you may want to anticipate growth for database values and report formats. You can constrain the values of the type through a range constraint that matches current needs. It is easier to modify the range and avoid redefining databases and reports.

Ada automatically truncates toward 0. If your requirements are to round the decimal result, you must explicitly do so using the 'Round attribute.

The core language defines the basic syntax of and operations on decimal types. It does not specify, however, the minimum number of significant digits that must be supported. Nor does the core language require the compiler to support values of Small other than powers of 2, thus enabling the compiler effectively to reject a decimal declaration (Ada Reference Manual 1995, §3.5.9). The Information Systems Annex provides additional support for decimal types. It requires a minimum of 18 significant digits. It also specifies a Text_IO.Editing package that provides support analogous to the COBOL picture approach.

See also Guideline 5.3.4.

You can use allocators and unchecked deallocation as is. Note that the degree to which explicitly deallocated storage is reclaimed might vary across implementations (Ada Reference Manual 1995, §13.11.2).

You use allocators as before. Instead of using unchecked deallocation, you maintain your own free lists of objects that are no longer in use and available for reuse.

You use allocators and possibly unchecked deallocation; however, you implement a storage pool and associate it with the access type(s) via a Storage_Pool clause. You can use this technique to implement a mark/release storage management paradigm, which might be significantly faster than an allocate/deallocate paradigm. Some vendors may provide a mark/release package as part of their Ada environment.

You do not use allocators, but instead use unchecked conversion from the address and do all your own default initialization, etc. It is unlikely you would use this last option because you lose automatic default initialization.

Using knowledge of the execution pattern of tasks to achieve timing requirements is nonportable. Ada does not specify the underlying scheduling algorithm, and there is no guarantee that system clock ticks will be consistently precise between different systems. Thus, when you change system clocks, your delay behavior also changes.