Typecast or not?

[Muetze1]

Zitat:

Zitat von Meflin

Nein, eben nicht wie ihr es sagt. Ihr sagt Umwandlung wäre etwas anderes als Cast. Es steht aber da, dass das äquivalente Begriffe sind...

Wie lange wollen wir das noch fortführen? In der reinen Programmierung ist ein typecast was anderes als eine Konvertierung/Umwandlung. Was der Unterschied ist: siehe mein vorheriger Post.

Was die Informatikprofessoren dazu sagen: unterschiedlich, aber am häufigstens die gleiche Ansicht wie mkinzler und ich. Und da es nun genug Quellen gibt die es mal ein hü und die anderen als hott bezeichnen, können wir das Spielchen noch lange so weiter treiben.

Grundlegend ist eine Unterscheidung zwischen Typecast und Umwandlung im täglichen Informatikergebrauch ein viel genauerer und damit präzisere Ausdrucksweise möglich. Es ist rein datentechnisch betrachtet ein gehöriger Unterschied und wenn der nicht klar ist, kann es leicht zu nicht funktionierenden Code kommen.

ABER: wenn einem der Unterschied egal ist bzw. man alles über einen Kamm schert und es sich erlauben kann, weil man es z.B. nie so detailliert betrachten muss, dann kann man auch beides als gleich ansehen und keinen Unterschied dazwischen machen. Der Kamm wäre hierbei typecast und drüber scheren tust du zum einen eine neu-Interpretation der Daten sowie eine Veränderung der Daten.

Jeder wie er will - wir sind ein freies Land.

[Cyf]

Zitat:

Zitat von Meflin

Wo bitte geschieht denn hier noch eine Typumwandlung - außer durch die Funktion int2byte??

Das war imho von ihm unglücklich formuliert, weil int2Byte hier eben keine Funktion, sondern ein expliziter Cast wäre, dass heißt, es wird nichts umgerechnet, nur anders interpretiert.

Während ein InttoStr in etwa sowas macht (legt jetzt keine Adresse in EAX und ist unsigned, aber habs grad noch da);

Delphi-Quellcode:

//Int <= High(Cardinal), 32-bit mit 32-bit Division, 35 Bytes Code
procedure MyInttoStr4(Int: Cardinal; P: PByte);
asm
  //Parameter: EAX: Int, EDX: P
  push ebx
  mov ebx, edx
  xor ecx, ecx // ecx = 0
  push cx // 16-bit Strinendezeichen auf den Stack
  mov cx, 10

  @Start:
  xor edx, edx // edx = 0
  div ecx //EAX: Ganzzahl, EDX: Rest; EDX:EAX / ecx
  add dl, 48 //ascii zahlencode in dl ('0': 48)
  push dx //ascii-code sichern
  or eax, eax // ganze Zahl auf 0 testen
  jnz @Start // wenn eax nicht 0 wiederholen

  @WriteBuffer:
  pop dx // ascii zurück
  mov byte [ebx], dl //ascii in den Buffer
  inc ebx //Bufferzeiger eins weiter
  or dl, dl //auf Stringende prüfen
  jnz @WriteBuffer

  pop EBX
  //ret wird automatisch am Ende erzeugt
end;

[alzaimar]

Meflin, IntToStr interpetiert eine Zahl als String. Genauso wie diese hier:

Delphi-Quellcode:

function DecToRoman(Decimal: Longint): string;
const
  Numbers: array[1..13] of Integer =
    (1, 4, 5, 9, 10, 40, 50, 90, 100,
    400, 500, 900, 1000);
  Romans: array[1..13] of string =
    ('I', 'IV', 'V', 'IX', 'X', 'XL',
    'L', 'XC', 'C', 'CD', 'D', 'CM', 'M');
var
  i: Integer;
begin
  Result := '';
  for i := 13 downto 1 do
    while (Decimal >= Numbers[i]) do
    begin
      Decimal := Decimal - Numbers[i];
      Result  := Result + Romans[i];
    end;
end;

Das ist kein Typecasting, sondern eine -ich wiederhole mich- Interpretation einer Zahl als folge arabischer Ziffern. Ebensogut könnten wir römische Ziffernfolgen, Maya-Glyphs oder ähnliche textuelle Repräsentationen von Zahlen verwenden. Das hat nichts mit Konvertierung im Sinne des Wiki-Artikels zu tun. Und schon gar nicht mit Typecasting.

Der Wiki-Artikel ist unglücklich formuliert, weil er zunächst Type conversion mit Type cast gleichsetzt.

Nach unserem Verständnis ist eine Konvertierung eine Überführung in einen anderen Datentyp, nach meinem Verständnis eben auch in den Datentyp 'Römische Zahlen als String'. Ich glaube, in diesem Verständnis liegt Dein Problem, meins übrigens auch. Ich musste den Artikel mehrmals lesen, um diesen Unterschied zwischen meinem Verständnis einer Konvertierung und dem im Wiki-Artikel zu verstehen. Im Übrigen ist der englische Artikel hier etwas genauer, aber unglücklich finde ich die Formulierung auch.

Für völlige Verwirrung würde übrigens der Einwand führen, das SQL hier Deine Definition nahelegt, zumindest Microsoft:

SQL-Code:

select cast (1 as varchar(10))

:stupid:

[flipdascript]

Ich schließe mich an mkinzler und muetze1 an. Bei einem Typecast wird der Compiler angewiesen ein ihn unter einem bestimmten Typ bekannten Speicherbereich als einen anderen Typ zu benutzen ohne das der Speicher verändert wird.
Bei einer Umwandlung a la IntToStr wird ein Speicherbereich als Typ Integer interpretiert und ein neuer Speicherbereich angelegt in dem das Resultat der Konvertierung geschrieben wird.

Was mir hier aber noch aufgefallen ist. Ich würd davon abraten Typecasts a la Type(Var) zu verwenden sondern stattdessen (Var as Type) oder falls es ein Pointer auf ein TObject ist (TObject(Pointer) as Type) zu verwenden da der Compiler euch dann vor falschen Zuweisungen bewahrt.

[Cyf]

Ich denke, das hängt von der Situation ab. Die Benutzung von as generiert zusätzlichen Code zur Fehlerüberprüfung, oder?

[flipdascript]

Ja, das kostet natürlich ein paar CPU Zyklen. Hat mir dafür aber schon so manche längere Bugsuche erspart. Gerade in größeren Projekten bei denen mehrere Leute dran arbeiten halte ich es für sinnvoll. Aber Du hast schon recht, es kommt drauf an was man machen will. Mir ist ein leicht langsameres Programm lieber als eines das ab und an abstürzt ;)