Overview
1. Comparisons between flat structures
2. Comparisons between single fields and structures
3. Comparison of deep structures
4. Comparison of internal tables
In general, operands that can be assigned to one another with the MOVEstatement can also be compared. Object references are an exception to this rule - they can be compared but not always assigned.
Structures can also be compared, even if they are not compatible. As in the
MOVE statement, the fragment views must be the same for the
length of the shorter structure. If the structures have different lengths, the shorter structure is
filled until it has the length of the other structure. All character type components are filled with
spaces and all other components with initial values of the right type - similar to assignments. The structures are compared fragment by fragment as defined by the Unicode fragment view.
The following rules apply when single fields are compared with structures:
Example
c0(10) TYPE C.
BEGIN OF struc,
c1(15) TYPE C,
i TYPE
I,
c2(5) TYPE C,
n(7) TYPE N,
END OF struc.
In this example,
c0
is extended to the length of
struc in storage. All areas > 10 are filled with initial
values of the correct type for components that are not character type and filled with spaces for other components.
As before, you can only compare two deep structures if they have compatible types. The compatibility
test for comparability was generalized so that structure components with references to classes or interfaces
can be compared with one another, whatever the class hierarchy and implementation relation, as for single fields. Only comparability of table types is required for table components.
Tables can be compared if their row types are comparable. The restrictions described above therefore also affect table comparisons.