Diskussion:Typumwandlung

aus Wikipedia, der freien Enzyklopädie

s.a. Diskussion auf Wikipedia:Löschkandidaten/15._November_2005 zu Typcast


C# als Referenzsprache im Artikel

es wäre fair, wenn hier C# als Referenzsprache für den Artikel erwähnt wird, Typumwandlungen soll se ja auch in Basic Lisp und Pascal geben.... 

-- 80.187.105.33 20:48, 9. Mai 2009 (CEST)
Was meinst du mit „Referenzsprache“? --j ?! 22:25, 9. Mai 2009 (CEST)

Überarbeiten

Die Einleitung ist zu knapp und nicht gut formuliert. Das verwendete Beispiel in der Einleitung fehl am Platz.

Zu sowas wie Es gibt explizite und implizite Typumwandlungen. kann man nur aha sagen - nichts für Ungut.

Das siehe auch Konvertierung (Informatik) sollte erklärt werden. In welchem Zusammenhang steht Konvertierung mit Typumwandlung? Gibt es Besonderheiten in anderen P-Sprachen? Wieso gerade ein Beispiel aus Java?

Man findet sicher auch ein paar brauchbare Quellen. Nun ja, viel gemeckert - aber ich kann's eben auch nicht besser. Wollte nur auf den Umstand hinweisen. Grüße --WissensDürster 19:39, 25. Mai 2009 (CEST)

So nun kann ich's besser. Hab aber noch keine Zeit... --WissensDürster 17:44, 1. Jul. 2009 (CEST)
Hab mal was geändert, aber noch folgende Frage: „Im Unterschied dazu erscheinen implizite Typumwandlungen nicht im Quelltext. Sie werden entweder nach durch die jeweilige Programmiersprache vorgegebenen Vorschriften oder gemäß einem vom Programmierer an einer anderen Stelle im Quelltext festgelegten Verfahren durchgeführt.“ Den letzten Teil verstehe/kenne ich nicht. Kann das jemand erläutern? ireas (talk’n’judge - DÜP) 18:48, 1. Nov. 2009 (CET)
Durch die Programmierspache vorgegeben wäre z.B. alle Kombinationen von 0...9 sind integer, oder? Meinst du mit "letzten Teil" das hinter dem oder? Vllt. kann ein Programmierer für gleiches Beispiel eine Art Script schreiben, das ihm diese Eigenschaft ersetzt, wenn sie eben nich von der Sprache vorgegeben ist ... ist einfach nur geschlussfolgert. Kenn mich in der Praxis kaum aus. Grüße --WissensDürster 18:56, 1. Nov. 2009 (CET)
Es gibt Programmiersprachen, in denen der Anwender eigene Typumwandlung(soperator)en definieren kann (z.B. C++). Diese werden dann eben an geeigneter Stelle automatisch vom Compiler benutzt. --RokerHRO 18:59, 1. Nov. 2009 (CET)
cool, richtig geraten^^ --WissensDürster 18:59, 1. Nov. 2009 (CET)
Das hätte ich wssen müssen; schließlich ist C++ die Sprache meines Herzens – ich war aber irgendwie blind :D Danke für die AW. ireas (talk’n’judge - DÜP) 19:57, 1. Nov. 2009 (CET)

Ist die Kritik am Artikel noch aktuell oder kann der Überarbeiten-Baustein nun raus? Falls noch Überarbeitungsbedarf besteht, bitte mal konkreter werden, sonst sehe ich das Thema als erledigt an. :-) --RokerHRO 14:04, 28. Jan. 2010 (CET)

@ „welche denn?“ – bspw. Java. Man sieht ja schon in dem Beispiel: von int zu double muß ich nichts machen, da int „ungenauer“ ist als double. Bei int zu byte muß ich jedoch casten, da aufgrund des geringeren Speicherplatz ein Genaugikeitsverlust oder ein anderer Fehler möglich ist.
@ ÜA: Das kann IMHO raus. Grüße, Robin (talk’n’judge - DÜP) 14:09, 28. Jan. 2010 (CET)
Okay, danke für das Java-Beispiel. Wie siehts mit der Umwandlung von int nach float aus? Das ist nicht immer sicher, umgekehrt genauso wenig. Was macht Java da? --RokerHRO 22:23, 28. Jan. 2010 (CET)
int zu float ist doch sicher, oder? Anders rum auf keinen Fall. Ich kann’s nacher aber mal ausprobieren. Grüße, Robin (talk’n’judge - DÜP) 07:08, 29. Jan. 2010 (CET)
Nein, ein 32-Bit-Float hat nur 23 Bit Mantisse, somit werden Ganzzahlen über 224 gerundet. Probier es aus: 16000001 -> float -> int = 16000001. Klappt also noch. Aber: 17000001 -> float -> int = 17000000. --RokerHRO 08:33, 29. Jan. 2010 (CET)

ungut

der artikel vermischt imho auf ziemlich üble weise casts und konvertierung. ich denke man sollte hier klar trennen, wo einfach nur dem typsystem bescheidgegeben wird, daß glaubt es besser zu wissen und wo tatsächlich daten in ein unterschiedliches format umgesetzt werden. die java-beispiele sind jedenfalls unbrauchbar - ein int mittels (byte) zu behandeln ist eine konvertierung, das betrifft den wert und nicht nur den typ! -- ∂ 22:00, 19. Feb. 2011 (CET)

nachtrag: schrieb ich auf [1] schonmal. vielleicht finde ich zeit, den artikel zu überarbeiten, ansonsten tendiere ich zum löschantrag. -- ∂ 22:02, 19. Feb. 2011 (CET)
So richtig trennen muss man nicht. Das Casten, wie du es definierst ist eher ein Spezialfall einer "echten" Umwandlung. Um das ganze zu klarifizieren, sollte man mE. eher klar zwischen statischem Typ, dynamischem Typ (falls Konzept vorhanden) und Wertrepräsentation unterscheiden. Wir haben es hier bei einer Typumwandlung mit 3 Funktionen auf 3 Ebenen zu tun, die gleichzeitig (durch die Sprache oder den Programmierer) definiert werden. Mal ein paar Beispiele:
  • Bei einem Cast nach deiner Def. ist die dritte einfach die Identität, die zweite nicht definierbar, und die erste die, die im Quelltext steht (falls nicht implizit).
  • Bei einem Cast in Java, der eine ClassCastException hervorrufen kann, ist die dritte auch die Identität (Zeiger bleibt der selbe), die zweite kann ich gerade nicht genau verorten, aber ich denke hier ist die Stelle, wo man die Identität-mit-Exception-Möglichkeit unterbringen muss. Die erste ist die, die im Quelltext steht (falls nicht implizit)
  • Bei Umwandlungen wie von int nach float sind alle drei Funktionen nicht-trival.
  • Bei benutzerdefinierten Umwandlungen, wie beispielsweise in C# möglich, sind ebenfalls alle drei Funktionen nicht-trivial.
(Man könnte natürlich auch einfach ein Lehrbuch zu Rate ziehen, das vorgibt, zu wissen, wie's richtig ist ^^ .)
Aber ja, ich stimme zu, die Java-Beispiele sind total unbrauchbar. Insbesondere das unter "Implizite Typumwandlung als Fehlerquelle" ist dämlich, denn die Fehlerquelle ist das überladene "/". --Daniel5Ko 22:55, 19. Feb. 2011 (CET)

hej Daniel5Ko! schön hier und so prompt von dir zu lesen. deine klassifizierung in 3 ebenen macht sinn, darauf ließe sich aufbauen. ich definiere "casten" tatsächlich im algol-sinne als spezialfall der typumwandlung, nämlich änderung des statischen typs bei beibehaltung des dynamischen typs und der wertrepräsentation. die einleitung erweckt aber zumindest bei mir den eindruck, type conversion und (type) cast wären synonyme zu typumwandlung - coercion fehlt mir da noch btw, die einleitung von en:Type conversion sieht mir beachtenswert aus. was mir an deiner aufteilung fehlt, ist eine klare abgrenzung von "ganz normalen" unären funktionen - sind das auch alles typumwandlungen? und, wenn ich z.b. in java ein int per (int) auf int "caste", ist das dann noch eine typumwandlungen, oder ist "cast" hier doch etwas ganz eigenes? -- ∂ 23:38, 19. Feb. 2011 (CET)

Die Abgrenzung zu "ganz normalen" einstelligen Funktionen ist schwierig, aber auch unnötig. Wenn man sich z.B. die C#-Spez. anschaut, dann muss man zu dem Schluss kommen, dass Typumwandlungen tatsächlich als normale Funktionen angesehen werden können, deren Aufruf lediglich eine andere Syntax hat (oder eine möglicherweise nicht vorhandene, falls implizit). Umwandlung von int nach int ist in gewisser Weise damit auch subsummiert, glaub' ich. --Daniel5Ko 11:59, 20. Feb. 2011 (CET)
Was man unter einem "Type cast" (unglücklich mit „Typumwandlung” eingedeutscht) versteht, hängt in der Tat sehr von der Programmiersprache (und den von ihr gebotenen Möglichkeiten und Konzepte) ab, in der man „denkt”. Ich kann da nur für C und C++ sprechen:
In C und C++ ist die Übersetzung mit Typumwandlung äußerst ungeschickt, denn in diesen Sprachen steht der Typ eines Ausdrucks ein für alle Mal fest und kann nicht geändert werden. Man kann nur aus einem bestehenden Ausdruck einen neuen Ausdruck erzeugen, der dann einen anderen Typ (und dannn einen „(möglichst) ähnlichen“ oder aber einen völlig anderen Wert) haben kann. Ob sich dabei der Wert ändert, hängt ganz von der Sichtweise ab: Hat der int-Ausdruck 2 einen anderen Wert als der double-Ausdruck 2.0? Viele meinen „Nein“, ist ja beides eine Zwei. Die Bitmuster sind jedoch total verschieden, bei Berechnungen verhalten sie sich auch anders. Noch gravierender sieht es mit 2.1 und (float)2.1 aus.
Es gibt in C++ in der Tat 4 verschiedene Cast-Operatoren für jeweils verschiedene Einsatzzwecke und dann noch die Altlast aus C: den C-Style-Cast, der auf subtile und bisweilen überraschende Weise 3 der 4 anderen Cast-Operatoren nachbildet.
Erwähnenswert fände ich allerdings noch, dass in C++ oft benutzerdefinierte Cast-Operatoren zweckentfremdet werden: Die C++-Standardbibliothek macht es vor mit dem Cast-Operator, der Standard-Streams nach void* castet, um sie dann in einem Booleschen Kontext zu verwenden. Wer mehr wissen will, möge nach "C++ safe bool idiom" googeln und sich am Kopf kratzen…
In vielen Skriptsprachen sieht es ganz anders aus, da ist es möglich, einem Objekt zu sagen: Du bist jetzt eine Ganzzahl, verhalte dich ab sofort auch so! Andere Sprachen kennen nur Strings und interpretieren die dann "je nach Kontext" mal als Zahl oder nicht (gelle, PHP).
--RokerHRO 01:08, 20. Feb. 2011 (CET)
Tja, und was machen wir nun :) ? --Daniel5Ko 11:59, 20. Feb. 2011 (CET)
Wir wenden §1 der alten Mecklenburgischen Landesverfassung an: „Alles blifft biem Ollen.“ :-) --RokerHRO 21:23, 20. Feb. 2011 (CET)

Idee

Wahrscheinlich kommt man nicht umhin, die ca. 4 bis 6 (?) verschiedenen Arten von "Typumwandlungen" beispielsweise in Tabellenform zusammenfassend gegenüberzustellen. Die Spaltenköpfe wären vielleicht sowas wie (Name/Kurzbeschreibung, Wirkung auf statischen Typ, Wirkung auf dynamischen Typ, Wirkung auf Wertrepräsentation). Einige Tabellenzellen (u.a. alle in der zweiten Spalte bei Typumwandlungsbegriffen, die aus dynamischen Sprachen stammen) würden zwangsläufig n/a enthalten. Die meisten Einträge in der ersten Spalte, wenn wirklich als Namen interpretiert, wären allerdings ein wenig TF-anrüchig. --Daniel5Ko 14:54, 20. Feb. 2011 (CET)

Nein. Sowas ist doch arg programmiersprachenabhängig und hier sollten nur die allgemeinen Konzepte dargestellt werden. Die Details können dann in den Programmiersprachen-Artikeln in epischer Breite behandelt werden. --RokerHRO 21:23, 20. Feb. 2011 (CET)
Denke ich eigentlich auch, aber wenn man dem Artikel hier sinnvolle Substanz geben will, läuft es auf etwas in der Richtung hinaus. --Daniel5Ko 21:27, 20. Feb. 2011 (CET)
allgemeine konzepte en detail mit ausgewählten beispielen aus handelsüblichen sprachen vielleicht? -- ∂ 21:30, 20. Feb. 2011 (CET)
Irgendwie so, ja. Das hätte allerdings auch eine gehörige Portion TF-Gschmäckle, besonders bei der Wahl der Namen der verschiedenen Typumwandlungsarten. Vielleicht ist Löschen doch die bessere Option. Die einfachste ist es sowieso. --Daniel5Ko 22:01, 20. Feb. 2011 (CET)
Dafür sind Diskussion(sseit)en wie diese hier ja da: Einen Konsens zu finden, mit dem zumindest diejenigen, die mitdiskutiert haben, leben können. :-) Den Artikel löschen würde ich jedenfalls nicht. --RokerHRO 22:49, 20. Feb. 2011 (CET)
K. Werden wir mal explizit und konstruktiv. Ich schlage vor, wir versuchen, so etwas wie die vorgeschlagene Tabelle zu basteln. Wenn dabei etwas sinnvolles 'rauskommt, kann man sie in den Artikel übernehmen. Als Anfang mal folgendes (Zum Abschuss und zur Editierung freigegegeben):

Tabelle

Name Wirkung auf stat. Typ Wirkung auf dyn. Typ. Wirkung auf Wertdarstellung
en:type punning Steht im Quelltext n/a id
Java/C#-Class-Cast; C++ Dynamic Cast usw. Steht im Quelltext id mit möglicher Exception id
Java-Cast bei Number-Primitiven Steht im Quelltext Steht im Quelltext sign-extend oder obere bits abgeschnitten oder (bei float) sonstiges
PHP-allerlei n/a zufällig gewählt zufällig gewählt
--Daniel5Ko 00:10, 21. Feb. 2011 (CET)
das doch mal ein anfang. ich war gleich so frech den (byte)(-4711)-fall einzubauen. was bietet uns denn C++ alles schönes? -- ∂ 00:41, 21. Feb. 2011 (CET)
Mir ist der Inhalt der Tabelle überhaupt nicht klar. Was ist ein D-Cast? Was ist mit 'id' und 'n/a' und 'Steht im Quelltext' genau gemeint? --RokerHRO 08:49, 21. Feb. 2011 (CET)
Ich hab' das 'D-"Cast"' genannt, weil das laut Benutzer:D ein Cast ist.
n/a: not applicable. Man kann nichts vernünftiges 'reinschreiben. id: Identische Funktion. "Steht im Quelltext" stimmt nicht so ganz weil es unvollständig ist, aber gemeint ist folgendes: Wenn im Code steht, dass zum Typ U gecastet werden soll, ist der statische Typ des Ergebnisses U. Ich glaube aber kaum, dass in dieser Spalte je etwas anderes als "n/a" oder "steht im Quelltext" passt. --Daniel5Ko 19:11, 21. Feb. 2011 (CET)

C++

Ich trag mal zusammen, was C++ so in Sachen "Typumwandlung" anbietet:

Kapitel Name Beispiel Bemerkungen
5.2.3 Explicit type conversion (functional notation) int i = int(d);
  • Ist nur mit simple-type-specifiern möglich, also Typnamen, die nur aus einem einzigen Wort bestehen (anderen Typen muss man vorher mit typedef einen eignen Namen geben)
  • Steht zw. den Klammern nur ein einziger Ausdruck, so ist T(e) äquivalent zu (T)e.
  • Zw. den Klammern können mehrere Ausdrücke stehen, wenn T eine Klasse ist, zu der es einen Konstruktor mit passender Argumentliste gibt.
  • T() erzeugt ein value-initialized Objekt vom Typ T.
5.2.7 Dynamic cast Derived* d = dynamic_cast<Derived*>(base_ptr);
  • Kann nur mit Zeiger- oder Referenztypen als Typparameter aufgerufen werden
  • Im Fehlerfall wird ein Nullzeiger zurückgegeben (bei Zeigertypen), oder eine std::bad_cast-Ausnahme geworfen (bei Referenztypen)
  • Benutzt ggf. RTTI, um zu entscheiden, ob der Cast durchgeführt werden kann. (Up-Casts sind stets möglich und brauchen somit kein RTTI. Down- und Cross-Casts dagegen benötigen RTTI und funktionieren somit nur mit polymorphen Typen)
  • Casts können mehrdeutig sein. Mehrdeutigkeiten führen ebenfalls zum Fehler.
5.2.9 Static cast int i = static_cast<int>(3.3); …
5.2.10 Reinterpret cast unsigned long addr = reinterpret_cast<unsigned long>(&some_object)
  • Das Mapping ist implementierungsabhängig (es ist nirgends gefordert, dass z.B. das Bitmuster identisch bleibt, auch wenn die meisten Compiler den Reinterpretcast so implementieren!)
  • Ganzzahl-Ausdrücke können in Zeiger gewandelt werden und umgekehrt. 2 aufeinanderfolgende Reinterpret-Casts von Zeiger -> Ganzzahl -> Zeiger (vom gleichen Typ) erhalten wieder den Originalwert, sofern der Ganzzahltyp groß genug ist, um alle möglichen Zeigerwerte aufzunehmen. Die Wandlung von Zeigern in Ganzzahlen soll für jemanden, der die plattformabhängige Darstellung von Zeigern kennt, „nicht überraschend“ sein.
  • Nullzeiger vom Typ T1 werden zum Nullzeiger vom Typ T2. Ganzzahlausdrücke mit Wert 0 werden zu Nullzeiger und umgekehrt.
  • …
5.2.11 Const cast char* s = const_cast<char*>(s); …
5.4 Explicit type conversion (cast notation) int i = (int)3.3;
  • „C-style cast”. Kann die Funktion von const_cast, static_cast und reinterpret_cast (in dieser Reihenfolge) übernehmen, wobei nicht offensichtlich ist, welche der Casts vorgenommen werden.
  • Da dies der einzige Cast in C ist, sind in C einige Klimmzüge nötig, um z.B. einen „Reinterpret cast” zu erzwingen, etwa wenn man das Bitmuster eines Double-Wertes als Ganzzahl interpretiert haben will.

Einleitung

"Datum" ist zwar sprachlich korrekt, aber die Verlinkung zu "Datum" als Kalenderdatum ist falsch. (nicht signierter Beitrag von 2003:C8:C721:1B00:28:7F75:F5F4:DAEC (Diskussion) 01:18, 10. Aug. 2022 (CEST))

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Typumwandlung&oldid=225218785“