TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Ada 83 to Ada 95 Transition Code Changes

This section addresses issues that come up specifically when moving from Ada 83 to Ada 95, or more precisely, from Apex Ada 83 to Apex Ada 95. Typically the changes are purely due to Ada dialect issues, but in some cases the issues are specifically due to the Apex implementations.

The following topics are covered here:


Pragma.1.ada

There are four runtimes, ts0 through ts3. Higher numbers support more complex scenarios, and thus have a higher overhead. For optimal speed, use the most restrictions appropriate for the code. Place this file, pragma.1.ada in every view used in a link.

The following four restrictions force ts2, ts1 or ts0:

Adding the following restriction forces ts1 or ts0:

Adding the following restriction forces ts0:

The following only restrict usage; they have no effect on speed:

The following should be enabled for maximum speed (at the sacrifice of runtime checking of range and other constraints). This is equivalent to the "-S" switch for VADS or "-O3 -gnatp" for GNAT:


System.Address incompatibilities

The System package has a different structure and layout in Ada 95 compared to Ada 83. In particular, address arithmetic with integers is different, requiring changes at every usage. It is possible to define a package which provides Ada 83 equivalent functions in such a way that optimization should remove any overhead, but we suggest converting over to the Ada 95 approach, as it provides a better abstraction.

Ada83

Package System defines address and integer mixing functions:

Ada95

Package System only defines address and a few constants:

Package System.Storage_Elements defines remaining address and integer mixings, but uses a integer derived type, not a sub-type of integer:

All usages must be changed accordingly. First, any "with"s must be modified:

Then any importation must be changed. If a use clause is in force, then it must be modified to specify use of System.Storage_Elements as well. If operators are imported using renames clauses, then we recommend also importing the Storage_Offset type:

Finally, any locations where the functions are used must be modified to convert the integer type to the Offset type defined:

This is relatively easy to do using the Apex GUI. Simply analyze the code, and all the appropriate "+" operators with problems will be highlighted. It is simple to then put "Offset(" right after the "+", and put a closing ")" at the appropriate end of the integer expression. Similarly, all "-" results can quickly be enclosed in a type conversion to Integer.

An alternative is to define a package that defines the same operations as the System package in Ada 83, and trust inlining and optimizations to eliminate all overhead. All places that use System must be changed, but if there was copious use of use clauses, then simply adding a with and use for this new package should suffice to convert the code. Functions in that package should minimally include:


Derived Type and Representation Specification Incompatibilities

Consider the following small example code:

Ada83

In Ada 83, the above code compiles and works fine. Note, however, that function "User_Function" is not defined for either Der_Type or Der_Type2.

Ada95

In Ada 95, the above code produces the following error when compiling Pkg_Child:

In Ada 95, both Der_Type and Der_Type2 have appropriate User_function functions defined and available. This is because in Ada 95 a derived type inherits all operations of the parent type.

The problem then, when converting Ada 83 code to Ada 95, is to disconnect the derived types from the primitive operations ("Image") in the parent package. This is conveniently achieved by defining a second type in the parent package, either a parent base type, or a derived child type, depending on usage within the application. Typically the parent type has more places where it is used, so it becomes desirable to create a parent base type as follows:

With this change, each derived type must be changed to point to the base type, which has no associated derived subprograms. In the unlikely case that there are a lot of derived type usage points, the original name can be used for the base type and a new name used for the child type within Pkg_Parent. If that is done, then all occurrences within the Pkg_Parent package must be changed appropriately, and any external usages changed as well.


Character literal type not resolvable

The following code is invalid in Ada 95 and valid in Ada 83:

Note that in Apex, the error message produced is not very helpful:

The error message indicates a problem with the index type, but fails to note that it is overload resolution that is the problem, not whether a character literal can be discrete.

The problem is that in Ada 95 there are two possible types for character literals, Character and Wide_Character. The context does not permit the overloading to be resolved. The simple fix is to add an explicit type:

It is also possible to use a subtype in this case to introduce the selected type:


Use of null strings ("") for user-defined string types fails (bug)

For user-defined string types (arrays of enumerated types that include character literals), the use of the null string ("") causes an compilation error in Ada 95. For example, the following code:

produces the following compilation errors with Apex Ada 95:

The same code compiles and runs without error under VADS and Apex Ada 83. This bug in Apex Ada 95 can be worked around simply by breaking the index type declaration into two steps as in the following workaround code:


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS