Assignments

Overview

1. Conversion between flat structures
2. Conversion between structures and single fields
3. Conversion between internal tables
4. Implicit conversions
5. Saving byte strings in character-type containers

This section deals with implicit and explicit type conversions using the equal sign (=) or the MOVE statement. Two fields can be converted if the content of one field can be assigned to the other field without triggering a runtime error.

For conversions between structured fields or a structured field and a single field, flat structures were previously treated like C fields. With the implementation of Unicode, this approach has become too error-prone since it is not clear if programs can be executed with platform-independent semantics.

Two fields are compatible if they have the same type and length. If deep structures are assigned, the fragment views must therefore be identical. One requirement in connection with the assignment and comparison of deep structures has been that type compatibility must exist between the operands which requires both operands to have the same structure. This requirement will continue to apply for Unicode systems.

1. Conversion between flat structures

To check whether two structures can be converted at all, the Unicode fragment view of the structures is set up initially by combining character type groups, byte type groups, alignment gaps, and other components. If the type and length of the fragments of the source structure are identical in the length of the shorter structure, the structures can be converted. Assignment is allowed under the following conditions:

  1. The fragments of both structures up to the second-last fragment of the shorter structure are identical
  2. The last fragment of the shorter structure is a character or byte type group
  3. The corresponding fragment of the longer structure is a character or byte type group with a greater length

If the target structure is longer than the source structure, the character type components of the remaining length are filled with blank characters. All other components of the remaining length are filled with the type-adequate initial value, and alignment gaps are filled with zero bytes. Since longer structures were previously filled with blanks by default, using initial values for non-character type component types is incompatible. This incompatible change is, however, rather an error correction. Character-type components are not filled with initial values, for the sake of compatibility.

Example

BEGIN OF struc1,                     BEGIN OF struc2,
  a(1) TYPE C,                         a(1) TYPE C,
  x(1) TYPE X,                         b(1) TYPE C,
END OF struc1.                       END OF struc2.

You cannot use the struc1 = struc2 assignment in Unicode, because struc1-x only occupies one byte, in contrast to struc2-b.

BEGIN OF struc3,                     BEGIN OF struc4,
  a(2) TYPE C,                         a(8) TYPE C,
  n(6) TYPE N,                         i    TYPE I,
  i    TYPE I,                          f   TYPE F,
END OF struc3.                       END OF struc4.

The struc3 = struc4 assignment is valie because the fragment views of the character-type fields and the integer numbers match.

BEGIN OF struc5,                     BEGIN OF struc6,
  a(1)  TYPE X,                        a(1) TYPE X,
  b(1)  TYPE X,                        BEGIN OF STRUC3,
  c(1)  TYPE C,                          b(1) TYPE X,
END OF struc5.                           c(1) TYPE C,
                                       END OF struc3
                                     END OF struc6.

However, struc5 = struc6 is not permitted - the fragment views of the two structure are different, because of the alignment gaps before struc3 and struc3-c.

BEGIN OF struc7,                     BEGIN OF struc8,
  p(8)  TYPE P,                        p(8) TYPE P,
  c(1)  TYPE C,                        c(5) TYPE C,
END OF struc7.                         o(8) TYPE P,
                                     END OF struc8.

The struc7 = struc8 works because the fragment views in the length of the structure struc1 match.

For deep structures, the operand types must be compatible as usual. We enhanced the concept by generalizing to some extent the convertibility of object references and table components.

2. Conversion between structures and single fields

The following rules apply for converting a structure into a single field and vice versa:

  1. If a structure is purely character type, it is treated like a C field during conversion
  2. If the single field is of type C, but only part of the structure is character type, conversion is only possible if the structure begins with a character type group and if this group is at least as long as the single field. Conversion now takes place between the first character type group of the structure and the single field. If the structure is the target field, the character type sections of the remainder are filled with blanks, and all other components are filled with the type-adequate initial value
  3. Conversion is not permitted if the structure is not purely character type and if the single field is not character type.

As with the assignment between structures, filling non-character type components with the initial value is incompatible. In addition, an incompatible semantic change results if the target is a single field of type N and parts of the structure content were previously relevant to conversion that do not originate from the first character type component.

  1. The conversion cannot be performed if the structure is not purely character-type and the single field is not of type C.



3. Conversion between internal tables

Tables can be converted if their row types are convertible. The restrictions described above therefore also effect the conversion of tables.



4. Implicit conversions

The above rules also apply to all ABAP statements that use implicit conversions according to the MOVE logic. For example, this is true for the following statements for internal tables:

The restrictions for explicit conversion also apply to the implicit conversion of VALUE specifications.



5. Saving byte strings in character-type containers

As with the numeric elementary types I and F , storing data objects with types X and XSTRING in character-type containers can be problematic. Under Unicode, the format of character-type data objects also depends on the byte order used on the individual platform. Therefore, the content of byte-type data objects is wrongly interpreted if such a container is stored persistently and subsequently imported on an application server with a different byte order.



Note

In the context of Structure Enhancements you should be aware of the categories used in the Dictionary.