Diskussion:Typisierung (Informatik)

Erster Kommentar

Die Einteilung ist nicht ganz schlüssig. Gewöhnlich wird nicht in 3 Kategorien, sonden in 2 Kategorien eingeteilt. Die Kategorien sind
schwache Typisierung (oder schwache Typbindung) Mischung mit Eigenschaften typloser Sprachen - Typen sind nicht disjunkt. Man könnte auch sagen, dass Schwach typisierte Sprachenunsichere Operationen zulassen. B (Vorgänger von C) ist eine typlose Sprache, die nur Maschinenworte kennt. Lisp,tcl typlose Sprachen oder solche mit einem Unersaltyp. Das reine Lambda-Kalkül ist ein extremes Beispiel für eine ungetypte Sprache, in der es nie zu einem Typfehler kommt. Als einzige Operation sind Funktionsanwendungen zugelassen und da alle Werte nur Funktionen sind, wird es bei dieser Operation nie zu einen Fehler kommen.. Perl ist typisch schwach typisierte Sprache. C läßt viele unsichere Operationen zu. (u.a. Zeigerarithmetik und casts)
starke Typisierung (oder starke Typbindung Typen sind disjunkt, alle Werte und Variablen (und gegebenefalls Objekte) haben einen eindeutigen Typ. Eine stark typisierte Sprache ist eine, in der alle legalen Programme gutes Verhalten zeigen. Pascal hat nur wenige unsichere Operationen (Variante Records ohne Tag-Feld,Funktionsparameter) Weitere Unterteilung der starken typisierung in statisch: Werden Programme statisch zur Compilezeit auf gutes Verhalten getestet und somit die Ausführung von unsicheren bzw. sich schlecht verhaltenen Programmen verhindert, spricht man von einer statischen Typüberprüfung.Also Typ wir zur Übersetzungszeit bestimmt. dynamisch: Untypisierte Sprachen oder schwach typisierte Sprachen können gutes Verhalten und sogar Sicherheit eines Programms erzwingen, in dem zur Laufzeit detaillierte Tests durchgeführt werden. Die Durchführung dieser Tests nennt man dynamische Typüberprüfung. Also Typ wird zur Laufzeit bestimmt.
Die Unterscheidung nach explizit und implizit getypte Sprachen ist eine andere Kategorie. Bei explizit getypten Sprachen sind die Typen Teile der Syntax, bei impliziten nicht. Eine stark typisierte Sprachen kann ja mit impliziter oder auch mit expliziter Typisierung stark typisiert werden! Das ist kein Widerspruch. Aber es scheint mir sehr fraglich, ob schwach typisierte Sprachen, bei denen keine Typen existieren oder diese nicht streng sind, man von einer impiziten/expliziten Typisierung spreechenkann, denn genau genommen findet eine Typisierung zum zeitpunkt der Programmerstellung eben nicht statt!
Das Problem auf einer Ebene über der Frage nach den Arten der Typisierung beginnt bereits bei der Unterscheidung zwischen typlosen (die gewöhnlich den schwach typisierten Sprachen zugeordnet werden) und typisierten Sprachen, siehe z. B. http://de.wikipedia.org/wiki/Programmiersprache: Um die üblichen Arten von Informationen im Computer abbilden zu können, müssen Möglichkeiten zur Definition von Daten oder Datenstrukturen bereitstehen, auch als Datentyp bezeichnet. Hierbei kann zwischen typisierten (zum Beispiel C++ oder Java) und typenlosen Sprachen (zum Beispiel JavaScript, Tcl oder Prolog) unterschieden werden. Bei typisierten Sprachen sind dies entweder vordefinierte Einheiten für einzelne Zahlen (Byte, Integer, Word, etc.) und Zeichen (Char) oder auch zusammengesetzte für Daten, Wörter, Text, sensorische Information und so weiter (Strukturen, Klassen). ...................... Bei den typisierten Sprachen gibt es solche mit Typprüfungen zur Übersetzungszeit (statisch typisiert) und solche in denen Typprüfungen primär zur Laufzeit stattfinden (dynamisch typisiert, etwa Ruby, Smalltalk). Werden Typfehler spätestens zur Laufzeit erkannt, spricht man von typsicheren Sprachen. Oft wird fälschlicherweise die statische Typprüfung wegen des angenommenen qualitativen Vorteils gegenüber der dynamischen Typprüfung als „sicher“ bezeichnet.
Diesr text stützt meine Einteilung im wesentlichen, womach nur starke Typisierung untertypen wie statisch und dynamisch zuläßt!
(Der vorstehende Beitrag stammt von 141.76.45.34 – 18:17, 7. Feb. 2007 (MEZ) – und wurde nachträglich signiert.)

Einteilung

Ich stimme zu, daß es in erster Linie um die Begriffspaare stark/schwach und (unter den stark typisierten) statisch/dynamisch geht. Unter den stark typisierten Sprachen sind vermutlich die meisten statisch typisierten auch explizit typisiert, und die meisten dynamisch typisierten (alle?) typisieren implizit; zumindest für letzteres sind mir Gegenbeispiele nicht bekannt bzw. fallen mir jetzt keine ein. Es wäre also vermutlich eine Tabelle nach dem Muster

Typisierung…	stark	schwach
statisch	i.d.R. explizit: Java, Pike; implizit: OCAML
dynamisch	i.d.R. implizit: Python	Javascript, PHP

sinnvoll.

• Das Pike-Beispiel überzeugt mich nicht davon, daß Pike auch dynamisch typisiert sei
• bei C muß man vermutlich zwischen K&R-C und ANSI-C unterscheiden, oder?
• bei Python kann anstelle einer float-Zahl zur String-Ersetzung (und auch sonst in allen praktisch relevanten Fällen; man korrigiere mich, wenn ich mich irre) ein int übergeben werden; dennoch ist Python stark typisiert (weswegen mir das C-Beispiel nicht reicht)
• ist Rexx typenlos? Alles ist ein String; Zahlen können als Strings verkettet werden („1 || 2“ -> „12“), in Zahlen konvertierbare Strings können als Zahlen addiert werden („1 + " 2"“ -> 3)

Kommentare, Korrekturen, Ergänzungen? --Tobias 01:58, 17. Okt. 2007 (CEST)

ganz interessant, und sogar halbwegs verständlich - aber könnte nicht endlich mal jemand Eingehweihtes die Formatierungskataswtrophe bereinigen?? 213.102.106.87 05:06, 9. Jan. 2009 (CET)

Vielleicht habe ich das eben gemacht (d. h., falls es das ist, was Du gemeint hast): Ich habe die Beispiele in ihre passenden source-Elemente gesteckt. Jetzt sind allerdings die Kommentare nicht mehr so gut lesbar; sie könnten möglicherweise in numerierte Listen unter den Beispielen verschoben werden (möglicherweise mache ich das noch). --Tobias 20:50, 12. Jun. 2009 (CEST)

C(++) Beispiel ist inkorrekt

Das Beispiel, das für die Typisierung von C/C++ geliefert ist, hat nichts im engeren Sinn mit der Typisierung der Sprache zu tun.

printf() "denkt" in diesem Fall nämich, der übergebene Speicherbereich sei im Format von double formatiert, was aber nicht der Fall ist, da der Compiler den Speicherbereich im int-Format übergibt.

Deshalb schlage ich vor, den Abschnitt in

int i=5;
float f=i;

oder so ähnlich umzuändern.

Ausserdem sollten, zumindestens wenn C (und nicht C++) als Sprache genannt wird, die Kommentare dieser Sprache benutzt werden. --Gamma01 07:26, 17. Jun. 2010 (CEST)

Eine etwas späte Anwort, aber: Das was du als "Format von double" bzw. "Format von int" bezeichnest ist doch gerade die Repräsentation von Typen (double bzw. int) im Speicher. printf interpretiert, wie du korrekt gesagt hast, den Speicherbereich der int-Variable als double um. Genau das ist in einer typsicheren Sprache nicht möglich. Und da Typsicherheit das wichtigste Ziel von Typisierung ist, hat das Beispiel sehr wohl mit Typisierung zu tun. -- 5.147.14.160 01:21, 3. Jan. 2014 (CET)

Einleitung

Ich finde die Einleitung zu diesem Artikel nicht sehr gelungen. Es sollte dort auch erläutert werden, was denn genau eine Typisierung ist (z.B. etwas in die Richtung "Übertragung von Eigenschaften") und nicht nur, wozu sie in einigen Programmiersprachen nützlich ist (es gibt ja auch genug Programmiersprachen, die ohne Typen auskommen).

--88.71.174.71 17:06, 21. Jan. 2013 (CET)

ich gebe dir insofern recht, als der Einleitungssatz nicht besonders glücklich formuliert ist, aber Programmiersprachen ohne Typen gibt es überhaupt nicht. Was du sicher meinst, ist, dass man nicht in allen Programmiersprachen als Programmierer über die Typen reden muss, weil sie nur in versteckter Form auftreten. (Der Fachmann spricht dann von latenten Typen). --Herbert Klaeren (Diskussion) 17:33, 21. Jan. 2013 (CET)

C++-Beispiel komplett falsch

Aus dem Artikel (eigene Kommentare in /* */):

int addmax(void **a, DWORD b, SHORT c) {
/* Was sind DWORD und SHORT? Existieren im Standard-C++ jedenfalls nicht */
    DWORD max = (DWORD)fmax(b, c); 
/* fmax ist falsch, std::fmax wäre korrekt; C-Style-Cast in C++ unüblich; expliziter Cast hier unnötig */
                                   // Aufruf von fmax(double b, double c) der Math Bibliothek
/* "Math Bibliothek"? Ist der <cmath>-Header gemeint? Header und Bibliotheken sind nicht dasselbe */
                                   // explizite Umwandlung double zu DWORD (mögl. Wertverlust)

    DWORD sum = *dynamic_cast(DWORD *)*a + max;
/* Syntax falsch (wo sind die <> zur Angabe des Types?); dynamic_cast hier falsch, denn nichts ist polymorph und void-Pointer werden mit static_cast umgewandelt */

                                   // Laufzeit-Konvertierung mit relativer Typsicherheit
/* Alle Konvertierungen geschehen zur Laufzeit */

                                   // Zugriff auf a oder dessen Inhalt kann Programmabsturz verursachen
/* Aha wieso? */

                                   // Konvertierung von *a kann eine Exception auslösen
/* Nein, dynamic_cast liefert einfach nullptr zurück */

    return static_cast<int>sum;    // typsichere Konvertierung zu int
/* Fehlerhafte Syntax, Klammern um den Wert vonnöten */
 }

Für mich ist der Code absolut unrettbar, sinnlos und falsch, daher habe ich ihn gleich gänzlich gelöscht. (nicht signierter Beitrag von Asfdlol (Diskussion | Beiträge) 12:17, 11. Dez. 2014 (CET))