Assignment Compatibility

Assignment Compatibility is in programming languages formulated instructions before, when terms and variables due to compatible data types each assigned to one another compared each other or linked may be.

With type-safe programming languages, compilers or interpreters can already check in the source text whether there is sufficient assignment compatibility. To fix a type violation , the compiler or interpreter must perform an implicit type conversion or an explicit type conversion by the programmer . In both cases, program errors can easily occur and, therefore, in many modern programming languages, implicit type conversion is only permitted in exceptional cases where it simplifies the source code but does not pose any danger.

Strict assignment compatibility

Assignments are allowed without restriction if there is strict assignment compatibility. To do this, the data types of the expression to be assigned and the variable must match exactly.

When connected , the number, sequence and data types of all components of the group must match, which can be ensured by declaring all variables involved with the same data type . Example:

TYPE Mann = Verbund von INTEGER alter; und REAL groesse;

VARIABLE otto, emil: Mann;

otto.alter   := 50;
otto.groesse := 1.80;

emil := otto; (Alle Attribute von „otto“ werden „emil“ zugewiesen)

The strict assignment compatibility is only given for fields if the basic data type and length are identical. Example:

TYPE Vorname = Feld der Größe 4 von CHARACTER; (Zeichenkette der Länge 4)

VARIABLE personename: Vorname;

personename := "Hugo";      (Die Konstante „Hugo“ ist zuweisungskompatibel zur Variablen „personenname“)
personename := "Alexander"; (Die Konstante „Alexander“ ist nicht zuweisungskompatibel zur Variablen „personenname“)

Open fields with undeclared length are a special case: In the case of formal parameters or fields that are dynamically only fully defined at runtime, the correspondence of the respective basic data type of the fields is sufficient to achieve assignment compatibility. Example:

TYPE Vorname = Feld von CHARACTER; (Zeichenkette mit offener Länge)

VARIABLE personename: Vorname;

personename := "Hugo";      (Die Variable „personenname“ wird dynamisch mit der Länge 4 erzeugt)
personename := "Alexander"; (Die Variable „personenname“ wird erneut dynamisch erzeugt, diesmal mit der Länge 9)

In the case of procedure variables, the number, type, sequence and data types of all parameters and return values ​​must match, i.e. apart from the procedure name, the signatures of the two procedures must match.

In this sense, two instances are assignment-compatible if they belong to exactly the same class . Example:

TYPE Rechteck = Klasse mit INTEGER breite, hoehe und mit Methode flaechenberechnung();

VARIABLE fenster1, fenster2: Rechteck;

fenster1.breite := 200;
fenster1.hoehe  := 100;
fenster1.flaechenberechnung(); (Flächenberechnung für „fenster1“ ausführen; Ergebnis = 20000)

fenster2 := fenster1; (Zuweisung ist möglich, da beide Instanzen derselben Klasse angehören)
fenster2.flaechenberechnung(); (Flächenberechnung auch für „fenster2“ ausführen; Ergebnis = 20000)

Logical compatibility

With a particularly strict approach, even two identical definitions of data types are not assignment-compatible, because although the data can be clearly transferred into one another (technical compatibility), two different definitions were used (logical compatibility). The following example would therefore be technically correct, but not logical:

TYPE Mann = Verbund von INTEGER alter; und REAL groesse;
TYPE Frau = Verbund von INTEGER alter; und REAL groesse;

VARIABLE otto: Mann;
VARIABLE anna: Frau;

otto.alter   := 50;
otto.groesse := 1.80;

anna := otto; (Zuweisung ist technisch möglich aber logisch nicht korrekt)

In order to avoid logical program errors, such assignments with implicit type conversion are not permitted in some programming languages ​​with relatively strong typing , such as Modula-2 or Oberon .

Allocation compatibility with no loss of information

In certain cases, the information that is stored in one data type can be transferred unambiguously and without loss of information to another data type.

Typical examples are integer data types with different memory sizes. In this way, an integer with a 16-  bit memory size can be clearly stored in a signed integer variable with a 32-bit memory size, without changing the number originally defined with 16 bits. Conversely, however, this is not always possible, especially if the signs and numbers are too large.

Further examples result from character strings or other fields whose fixed length is different. The shorter field can be stored in the longer one, but not the other way around.

Two instances are assignment compatible without loss of information if the class to be assigned belongs to the same class as the assigned class.

Assignment compatibility example

zahl1: BYTE; (mit 8 Bit für ganze Zahlen von −128 bis +127)
zahl2: SHORTINT; (mit 16 Bit für ganze Zahlen von −32768 bis +32767)

zahl1 := 55; (Zuweisung der ganzen Zahl 55 an die Variable „zahl1“)
zahl2 := zahl1; (Zuweisung der ganzen Zahl 55 aus der Variablen „zahl1“ an die Variable „zahl2“)

Example with no assignment compatibility

zahl1: BYTE; (mit 8 Bit für ganze Zahlen von −128 bis +127)
zahl2: SHORTINT; (mit 16 Bit für ganze Zahlen von −32768 bis +32767)

zahl2 := 555; (Zuweisung der ganzen Zahl 555 an die Variable „zahl2“)
zahl1 := zahl2; (Ungültiger Versuch der Zuweisung der ganzen Zahl 555 aus der Variablen „zahl2“ an die Variable „zahl1“)

With such an assignment, the compiler can already prevent executable machine code from being generated, since it cannot be guaranteed that large numbers that are stored in the variable “number2” can always be stored in the variable “number1” without any loss of information.

If there is no check by the compiler, digits will inevitably and unnoticed be cut off, so that in subsequent calculations gross calculation errors may occur, some of which are difficult to analyze.

Allocation compatibility with little loss of information

A special case is the assignment of whole numbers to variables that represent floating point numbers . In most cases, it can be tolerated without the risk of program errors to implicitly convert large whole numbers into floating point numbers, since the calculation error (if any) is very small here. This can also be illustrated with an example:

zahl1: LONGINT; (mit 64 Bit für ganze Zahlen von  ${\displaystyle {-2}^{63}}$ bis  ${\displaystyle {+2}^{63}-1}$)
zahl2: REAL; (mit 64 Bit für Gleitkommazahlen mit einer Mantisse mit maximal 14 Nachkommastellen nach IEEE 754)

zahl1 := 9223372036854775807; (Zuweisung der ganzen Zahl  ${\displaystyle {2}^{63}-1}$ an die Variable „zahl1“)
zahl2 := zahl1; (Gültiger Versuch der Zuweisung der ganzen Zahl  ${\displaystyle {2}^{63}-1}$ aus der Variablen „zahl1“ an die Variable „zahl2“,
                 die allerdings anschließend den gerundeten Zahlenwert  ${\displaystyle 9{,}22337203685478\cdot {10}^{18}}$ enthält)

The error caused by truncating the last decimal places is only of the order of magnitude and can therefore be neglected for practically all applications. ${\displaystyle {10}^{-14}}$

Allocation compatibility with defined loss of information

Two instances are assignment-compatible with a defined loss of information if the class to be assigned belongs to a class derived from the assigned class . All data in the assigned class declared and are thus required to be allocated, but added in the allocated, derived class attributes and methods ignored. Example:

TYPE Lebewesen = Verbund von INTEGER alter, gewicht;
TYPE Mensch = Lebewesen mit INTEGER intelligenzquotient; (Der Datentyp "Mensch" erbt alle Eigenschaften von Lebewesen)

VARIABLE otto: Mensch;
VARIABLE eukaryot: Lebewesen;

otto.alter               := 50;
otto.gewicht             := 75;
otto.intelligenzquotient := 100;

eukaryot := otto; (Zuweisung ist korrekt, das Attribut "intelligenzquotient" wird jedoch nicht zugewiesen)

Assignments without type safety

Programming languages ​​that were designed for machine-level programming , such as C , often have no or only a very weak type test . This tolerance easily leads to program errors .

pointer

In some programming languages, such as C, it is allowed to assign any pointers to a pointer variable without checking or being able to check whether the data types of the referenced data are identical or compatible.

Truth values

In some older programming languages, such as C, there is no separate data type for two-valued Boolean variables . The integer data type with the smallest memory requirement is then often used to handle and process the corresponding information, with the numerical value zero being used for the truth value "false" and all other numerical values ​​for the truth value "true". Here, too, arise logical incompatibilities and thus complications as binary values not arithmetic , not with numbers logic operations or logic operations can be performed. The following example illustrates this abuse:

VARIABLE falscheWahrheit1, falscheWahrheit2, ergebnisWahrheit: INTEGER (ganze Zahlen)

falscheWahrheit1 := 0; (0 soll den Wahrheitswert Falsch repräsentieren)
falscheWahrheit2 := 1; (1 soll den Wahrheitswert  Wahr  repräsentieren)

ergebnisWahrheit := falscheWahrheit1 + falscheWahrheit2;   (Ergebnis dieser unsinnigen arithmetischen Addition ist 1,
                                                            was für den Wahrheitswert  Wahr  steht)

ergebnisWahrheit := falscheWahrheit1 UND falscheWahrheit2; (Ergebnis dieser logischen Konjunktion ist 0,
                                                            was für den Wahrheitswert Falsch steht)

ergebnisWahrheit := falscheWahrheit2 + falscheWahrheit2;   (Ergebnis ist 2 und zuweisungskompatibel,
                                                            aber ohne logischen Sinn)

A clear and correct implementation could look like this:

VARIABLE richtigeWahrheit1, richtigeWahrheit2, ergebnisWahrheit: BOOLEAN (Wahrheitswerte)

richtigeWahrheit1 := FALSCH; (nur Wahrheitswerte sind zuweisungskompatibel)
richtigeWahrheit2 := WAHR;   (nur Wahrheitswerte sind zuweisungskompatibel)

ergebnisWahrheit := richtigeWahrheit1 UND richtigeWahrheit2; (nur logische Operatoren sind zulässig, und nur Ergebnisse
                                                              mit Wahrheitswerten (hier FALSCH) sind zuweisungskompatibel)

amounts

The same applies to the links between sets . If a distinction is not made here between quantities (bitsets) and numbers for the data types and permitted operators, there are problems of interpretation, for example when determining difference quantities :

VARIABLE falscheMenge1, falscheMenge2, differenzMenge: INTEGER (ganze Zahlen)

falscheMenge1 := 0; (0 soll eine leere Menge repräsentieren)
falscheMenge2 := 1; (1 soll eine Menge mit dem Element 1 repräsentieren)

differenzMenge := falscheMenge1 - falscheMenge2; (Ergebnis dieser unsinnigen arithmetischen Subtraktion ist −1)

A clear and correct implementation could look like this:

VARIABLE richtigeMenge1, richtigeMenge2, differenzMenge: BITSET (Mengen)

richtigeMenge1 := { }; (soll eine leere Menge repräsentieren)
richtigeMenge2 := {1}; (soll eine Menge mit dem Element 1 repräsentieren)

differenzMenge := richtigeMenge1 - richtigeMenge2; (Nur Mengen-Operatoren sind zulässig,
                                                    und nur Ergebnisse mit Mengen (hier ist das Ergebnis die leere Menge)
                                                    sind zuweisungskompatibel)

literature

• Hanspeter Mössenböck : Appendices to the language definition - definition of terms, Chapter A.12.1, in: Object-oriented programming in Oberon-2 , Verlag Springer 1998, ISBN 978-3-5406-4649-5

Web links

• Stefan Middendorf, Reiner Singer, Jörn Heid: Assignment compatibility in: Object-oriented programming with Java, The Java language, programming manual and reference for the JavaTM-2 platform , 3rd edition 2002
• Uwe Schmidt: Assignment compatibility in: Object-oriented programming with Java, Wedel University of Applied Sciences

Individual evidence

1. ↑ Kathleen Jensen, Niklaus Wirth, Andrew B. Mickel: Assignment Statements , in: Pascal user manual and report: ISO Pascal standard , Chapter 9.1.1, page 170, Verlag Springer 1991, ISBN 978-0-3879-7649-5
2. ↑ László Böszörményi, Jürg Gutknecht, Gustav Pomberger: Symbol Table Handling , in: The school of Niklaus Wirth: the art of simplicity , pages 61 and 62, Verlag Morgan Kaufmann 2000, ISBN 9781558607231
3. ↑ Joel Pitt: Volition Systems Modula-2 Programming Language , in: InfoWorld, September 19, 1983, Volume 5, Number 38, InfoWorld Media Group, ISSN  0199-6649
4. ↑ Kent Lee: Example 8.2 , in: Programming Languages: An Active Learning Approach , Chapter 8, Pages 228 and 229, 2008, ISBN 9780387794211