Diskussion:Datentyp

aus Wikipedia, der freien Enzyklopädie

Verschiebehinweis

Der Abschnitt Eigenschaften abstrakter Datentypen wurde von Benutzer:Martin Sebastian Panzer erstellt und aus dem Artikel Eigenschaften abstrakter Datentypen von mir hierher verschoben. Ich werden die Artikel Eigenschaften Abstrakter Datentypen und Eigenschaften abstrakter Datentypen in einigen Tagen zur Schnelllöschung vorschlagen, da kein sonstiger Link darauf verweist. --Friese 17:40, 29. Jun 2004 (CEST)

Ein Datentyp und ein abstrakter Datentyp sind nicht dasselbe. Statt eines falschen Redirects (vgl Wikipedia:Redirect sollte daher vielmehr der Abschnitt sogar ausgelagert und sinnvoll verlinkt werden. Lange Texte, die gleich mehrere Sachen definieren, verhindern Interwikilinks und sorgen regelmäßig für das Mehrfachanlegen von Artikeln. Kleine Artikel sorgen für das schnelle Auffinden von Informationen. Daher lieber kleine Artikel mit abgeschlossenem Inhalt. 128.176.114.194 20:19, 29. Jun 2004 (CEST)

Ein Abstrakter Datentyp ist eine spezielle Form eines Datentyps. Die Länge des Artikel halte ich für noch angemessen. Ich hatte ja auch nur die Seite zu den Eigenschaften der ADT integriert. Es werden ja nicht zu jedem Eintrag in der Wikipedia zusätzlich noch Eigenschaftssseiten erstellt.
Gegen eine eigene Seite für Abstrakte Datentypen wäre ich nicht zwingend, jedoch nur dessem Eigenschaften auszulagern halte ich nicht für sinnvoll. Da es grundlegend nur diese drei möglichen Datentypen-Arten gibt, würde ich sie aber lieber auf einer Seite belassen.
Wegen des Verweis auf Wikipedia:Redirect verweise ich auf den Abschnitt 'Mehrere Begriffe in einem Artikel' in Wikipedia Diskussion:Redirect. Solch ein Fall liegt hier meiner Meinung nach vor.
Wenn man jedoch die ADT auslagert, muss man konsequenter Weise auch eigene Artikel für die Elementaren und die Zusammengesetzten Datentypen erstellen.--Friese 18:26, 30. Jun 2004 (CEST)
Ich wüsste eigentlich nicht warum abstrakte Datentypen nicht ihm Artikel Datentypen beschrieben werden sollten. Ich denke auch, dass der Artikel, so wie er zur Zeit ist, nicht zu lang ist. Ich find das so übersichtlicher, als wenn man da wieder drei oder vier einzelne Artikel daraus macht. Also wegen mir kann alles so bleiben, wie es ist - aber ich will hier auch nichts blockieren... --Martin~ 00:15, 1. Jul 2004 (CEST)


Zeigertypen

Ich bin mir ziemlich sicher, dass Zeigertypen nicht zu den elementaren Datentypen gezählt werden (siehe u.a. auch [1]), deshalb hab ich das mal etwas umgegliedert.

Ein Datentyp mit Namen "Nulltyp" ist mir nicht bekannt. Bei Pascal steht in der Beschreibung von Nil, dass es eine "Zeigertypenkonstante, die auf nichts zeigt" ist. Seid ihr euch / Bist du dir wirklich sicher, dass es sich hier um einen eigenen Datentyp handelt und wenn ja: für was verwendet man ihn? --Martin~ 00:15, 1. Jul 2004 (CEST)

Nein, bin ich mir tatsächlich nicht, dass mit dem konstanten Zeiger ist natürlich genauer und richtiger. Ich hab es angepaßt. Friese 18:12, 1. Jul 2004 (CEST)

Boolean

Boolean ist ein spezieller Aufzählungstyp. Meiner Meinung nach sollte er auch als solcher gekennzeichnet bleiben. Ich hab das mal dementsprechend gekennzeichnet. Friese 18:27, 1. Jul 2004 (CEST)

Definition von Endlichkeit, Ordinalität usw.

Ich finde die Definition der elementaren Datentypen über die Endlichkeit und insbesondere die Diskretheit fragwürdig. Auch ein Array ist nach der Definition 'festgelegte' Anzahl von Werten Diskret. Die Anzahl der Elemente ist ebenfalls endlich. Wo hast du das her ? Die Definition von Ordinal und nichtordinal über die Beschreibung des Vorgängers und Nachfolgerprinzips ist vielleicht etwas länglich. Ich würde eher den Begriff Ordnungsrelation verlinken, der erklärt auch geordnete Menge. Was meinst Du ? Friese 19:13, 1. Jul 2004 (CEST)

Diskussion zur Grunddefinition

Ich habe gerade einige Sachen umformuliert und wollte einen Teil davon gerne begründen, damit niemand auf die Idee kommt, es wieder falsch zurückzuändern.

  • Ein Datentyp besteht nur in bestimmten Fällen der objektorientierten Programmierung aus Wertebereich und Operationen, im allgemeinen Fall jedoch nicht
  • Eine Wertemenge ist etwas anderes als ein Wertebereich, weil eine Menge mehrere Elemente eines Bereichs aufnehmen kann
  • Die Annahme, daß es einen allen Programmiersprachen zugrundeliegenden Satz ähnlicher elementarer Datentypen gäbe, ist falsch. Insofern könnte man am ganzen Artikel noch etwas tun. Mh 17:16, 17. Jul 2004 (CEST)
Deine Änderungen finde ich fast ausnahmslos sehr gut, da sie den Sachverhalt noch genauer und konkreter ausdrücken. Den Verweis auf die Variable am Anfang habe ich um die Kostante erweitert, da es wie du in Speicherbereich richtig schreibst, auch eine Konstante sein könnte. Zu deiner Feststellung bei objektorientierten Sprachen: Was sind es denn, wenn nicht Datentypen, kannst du bitte ein Beispiel angeben. Klassen sind z.B. nach meiner Kenntnis keine Datentypen. Das es objektorientierte Sprache wie Smalltalk und C# gibt, bei denen Datentypen selbst Objekte sind, ist mir klar, aber macht das in der Definition des Datentyp einen wirklichen Unterschied, so dass man es hier erwähnen muss. Was meinst Du ? Zu deinem letzten Punkt: Welche Sprachen verwenden denn gar keine Typisierung ? Dann sollte man das aufnehmen. --Friese 17:56, 17. Jul 2004 (CEST)
Üblicherweise werden OOP-Klassen als abstrakte Datentypen gesehen, weil man (zumindest bei der "reinen Lehre" - ob man in der Praxis immer so programmiert, ist eine andere Frage) nur über Methoden (die hier die Operatoren sind) darauf zugreifen kann. Das bringt mich auf die Idee, daß ich Objekttypen ja eigentlich noch unter "abstrakte Datentypen" einfügen könnte...
Mit dem letzten Punkt meine ich z. B. Sprachen wie C, die keine Strings kennen (sondern nur Characterkonstanten) und einige noch ältere Sprachen (z. B. den C-Vorgänger BCPL), die noch gruseliger sind. Mh 20:07, 17. Jul 2004 (CEST)
Das stand dort schon mal. Jedoch mit den Hinweis, dass Klassen abstrakte Datentypen plus Polymorhpie und Vererbung sind. Ich habe das mit voller Absicht entfernt, da Klassen im Regelfall (Ausnahme Datentypen, die auf Klassen beruhen (C#)) keinen Wertebereich oder sowas kennen. Sie sind mehr als abstrakte Datentypen, die wenigstens mit ihrer Ausprägung auf ein bestimmtes Element wertebereich - gebunden werden.
Zu C (BCPL kenne ich nicht): Auch C hat, wenn auch wenige, vordefinierte Datentypen.
Aber ich habe deshalb im zweiten Satz vorsichtiger Weise aus Alle das Wort Viele gemacht. --Friese 21:28, 17. Jul 2004 (CEST)
Ich habe die Änderung im ersten Satz nochmal genauer angeschaut, so wie du es jetzt definierst ist ein Datentyp ein Wertebereich. Nach meiner Kenntnis und so definiert es z.B. auch der Duden der Informtik, liegt der Schwerpunkt beim Datentyp genau auf der konkreten Zusammenfassung von Wertebereich und den darauf definierten Operationen. Die konkrete Ausprägung welcher Wertebereich und welche Operationen zusammen einen Datentyp bilden, ist jedoch wirklich stark programmiersprachen abhängig. Ich habe also den ersten Satz deshalb noch mal geändert, um dies deutlicher zu machen. --Friese 18:24, 17. Jul 2004 (CEST)
Dumm gelaufen, genau diese Formulierung war nämlich Absicht und ich habe lange daran getüftelt, bis ich zufrieden war. Ich habe länger drüber nachgedacht und bin mittlerweile der festen Überzeugung, daß der Duden Unrecht hat. Aus theoretischer Sicht (Algebra) gibt es auch Datentypen, die sind wie im Duden definiert. Aus praktischer Sicht erlauben viele Programmiersprachen die Definition eigener Operatoren, abgesehen davon, daß Operatoren sowieso sowohl aus theoretischer als auch fast immer aus praktischer Sicht (fast) normale Funktionen mit einer ungewöhnlichen Notation sind. Ich würde aber nicht sagen, daß man durch einen neuen Operator (der ja auch nur eine spezielle Funktion ist) oder eine neue Funktion den Datentyp neu definiert. Darum sehe ich es nicht so, daß die Operatoren Bestandteil des Datentyps sind, sondern daß zum Datentyp gehört, daß es bestimmte (!) Operatoren gibt, die auf ihn angewendet werden können. Mh 20:07, 17. Jul 2004 (CEST)
Du hast natürlich Recht, dass fast jede Programmiersprache das Definieren neuer Funktion auf Datentypen zulässt. Ebenfalls richtig ist, dass diese sich praktisch fast gar nicht von den Operationen (also das standardmäßig in der Programmierspracge verfügbare) unterscheidet. Jedoch ist es formal so, dass die vordefinierten Datentypen in einer Programmiersprache nun mal dass sind, was allen Programmieren als Minimalunterstützung an die Hand gegeben wird. J. Nievergelt erklärt im Informatik-Handbuch Kap. D1 1.1 und 1.3( und dort(1.1) werden Datentypen auch so definiert, wie ich es in den Artikel geschrieben habe) zu diesem Thema ganz plastisch, dass die vorgegebenen Datentypen der Programmiersprachen nur sogenannte Elementaroperationen beinhalten. Komplexere Datentypen werden aus diesem aufgebaut.
Ich stimme mit Dir deshalb an dem Punkt des Hinzufügens neuer Operationen/Funktionen nicht überein. Mit einer neuen Funktion wird ein Datentyp zu einem neuen Datentyp, erweiter, der anders ist. Ein Beispiel, ein Stack, der mehr kann als push,pop, isempty und top ist eben kein klassicher Stack mehr, sondern irgendein neuer Stack-Datentyp. Aber ich glaube so langsam wird das philosophisch. Ich tendiere aber immer noch dazu das Lemma so zu belassen, da es in den mir bekannten Fachbüchern so zu finden ist. Vielleicht kann man deinen praktischen Einwand irgendwie unterbringen, also das die Grunddatentypen einfach durch Definition neuer Operationen aufgebohrt werden können und normalfall sogar aufgebohrt werden müssen, um damit etwas sinnvolles anzufangen. --Friese 21:28, 17. Jul 2004 (CEST)

Klassen und Datentypen

Wir hatten unter C# schon einmal das Thema, ob Klassen Datentypen sind, oder nicht. In der englischen Wikipedia bin ich jetzt auf folgenden Artikel gestoßen: data type. Danach wird eine Klasse als Datentyp angesehen. Was ist nun richtig? Zäh-Scharp 17:20, 14. Aug 2004 (CEST)

Also ich hatte mir den englischen Artikel schon mal durchgelesen, mir war es damals auch aufgefallen. Ich komme jedoch heute wie damals zu dem Ergebnis, dass ich den englischen Artikel ein wenig am Thema vorbeigeschrieben finde. Er erklärt eigentlich viel mehr, welche verschiedenen Arten von Typisierung es gibt, z.B. statische und dynamische Typprüfung, schwache und starke Typbindung in den Programmiersprachen. Bei der tatsächlichen Erklärung von Typen werden nur Links auf andere Artikel angegeben. So kommt es, dass z.B. Funktionen, Protokolle, Schnittstellen und eben auch Klassen als Datentypen-Kategorie angegeben werden. Möchte man sich dann mal anschauen, was ein Class type denn sein soll, so landet man mit einem redirect bei Class (computer science). Insgesamt finde ich dass in der engl. Wikipedia nicht wirklich überzeugend. Also würde ich hier einfach mal ein wenig arrogant behaupten, unser deutscher Artikel ist deutlich besser, wenn auch in der dt. Wikipedia noch Informationen zu strong und weak typing fehlen usw., weil der Begriff Datentyp bei uns wirklich erklärt wird. Sonst müssten wir als nächstes ja auch Funktionen als Datentypen aufnehmen und da bin ich mir nun wirklich sicher, dass sie es nicht sind. Summa summarum: Ich bin immer noch dafür eine Klasse nicht als Datentyp aufzunehmen, habe aber nichts gegen ein Satz der Art: Ob Klassen zu den Datentypen gezählt werden ist umstritten, da sie noch zusätzlich die Eigenschaften der Polymorphie und Vererbung besitzen sowie oft keinen zugehörigen Wertebereich haben. Na ja oder so ähnlich. --Friese 19:40, 26. Aug 2004 (CEST)
Die Auflösung der Widersprüche besteht darin, dass es eben unterschiedliche Terminologien gibt. In der einen Terminologie ist eine Klasse ein Datentyp, in der anderen nicht. Mit anderen Worten: Es gibt eben verschiedene Definitionen, sowohl für "Datentyp" als auch für "Klasse", und so würde ich es auch in dem Artikel darstellen. Zäh-Scharp
Da spricht ja nichts dagegen, wenn du eine weitere Definition für Datentypen zur Hand hast (und womöglich auch noch eine Quelle) und sie als weitere (Alternativ-)Definition in den Artikel integrierst. Allerdings ging es dir doch mehr um die Frage, ob eine Klasse ein Abstrakter Datentyp ist. Dann sollte dies vielleicht auch dort aufgenommen werden. --Friese 23:11, 4. Nov 2004 (CET)

Neues Lemma: Signatur ??

Kann mir jemand das neue Lemma erklären. Ich habe den Begriff Signatur in diesem Sinnzusammenhang noch nicht gehört und wieso wird die Definition auf Objektmengen ausgedehnt. Damit ist man doch viel eher bei der Datenstruktur respektive dem Abstrakten Datentyp ?? --Friese 22:54, 28. Nov 2004 (CET)

Wir haben bei Themen wie diesem generell das Problem, dass viele Autoren die Begriffe aus programmiersprachlichen Erfahrungen heraus kennen, nicht aber die ausgiebig erforschten formalen Zusammenhänge. Der Artikel, wie er jetzt ist, behandelt nur den programmiersprachlichen Aspekt. Der Begriff Datentyp ist jedem bekannt, der schon einmal programmiert hat. Er ist jedoch aus der Sicht eines Informatikers im Grunde von der Programmierung erst einmal unabhängig und kann ohne Bezug auf Implementierungsaspekte untersucht werden. Tatsächlich werden Algorithmen (und die dazu komplementären Datentypen) meist ohne jeden Bezug zu einer konkreten Implementierung entworfen. Wer den Begriff Datentyp also mit einer programmiersprachlichen Terminologie beschreibt, greift eindeutig zu kurz. Tatsächlich ist die Verwendung im Sinne von abstrakten Datentypen schon viel korrekter. Aber man muss sich bewusst machen, dass Datentypen im Grunde noch keine Semantik haben. Man hat es nur mit einer Signatur zu tun, ohne zu wissen, für welche Objekte die Sorten und für welche Funktionen die Operationssymbole stehen. Abstrakte Datentypen hingegen enthalten schon eine Semantik: Den Sorten-Namen werden Objekte zugeordnet, den Operations-Namen werden Funktionen zugeordnet. Das ist in einer Signatur noch nicht der Fall. Man sollte dem Artikel einen Abschnitt "Formale Definition eines Datentyps über eine Signatur" gönnen und dann die programmiersprachlichen Aspekte unter einem weiteren Abschnitt "Datentypen in Programmiersprachen" behandeln. Allerdings fehlt mir in dieser Woche die Zeit für eine derartige Umarbeitung. Falls du vorläufig die Änderungen reverten willst, da sie nicht mehr ideal zum Rest des Artikels passen, fände ich das ok. Allerdings sollte man im Sinn behalten, dass der Artikel in der jetzigen Form nur den programmiersprachlichen Aspekt von Datentypen erfasst und damit einer umfassenden Erklärung des Begriffes nicht gerecht wird. Viele Grüße --Mkleine 23:47, 28. Nov 2004 (CET)
Ich habe den Artikel nun doch noch in oben erläutertem Sinn ergänzt. Falls Fragen bleiben, stehe ich gerne zur Verfügung.--Mkleine 02:28, 29. Nov 2004 (CET)
Deine sehr gelungene Erweiterung des Artikels erinnert mich grausam daran, dass mein Studium nun schon etwas länger zurückliegt und doch einiges Wissen verschütt gegangen ist. Ich habe nach ein wenig Literaturrecherche die Einleitung noch mal ein wenig umgestellt. So wird es aus meiner Sicht noch klarer. Was meinst Du ? Mein Literaturausflug zeigt mir, dass selbst die Beschreibung durch eine Signatur noch nicht vollständig ausreicht, da zu Datentypen auch noch Axiome über das Verhalten hinzukommen können, die nicht durch Operationen sichtbar werden.--Friese 22:37, 30. Nov 2004 (CET)

Softwaremäßige Emulation

Was versteht man unter der softwaremäßigen Emulation von Datentypen? Das habe ich im Artikel Befehlssatz gelesen. Vielleicht kann man das hier noch einarbeiten? Danke, --Abdull 13:42, 16. Mär 2005 (CET)

"Algebren"

Der Satz: "Die Konkretisierung der Operationsmenge führt zu Abstrakten Datentypen beziehungsweise Algebren", verlinkt auf das mathematische Teilgebiet "Algebra", zu dem es keinen Plural gibt. Ist vielleicht algebraische Struktur das richtige Linkziel?-- Gunther 00:29, 17. Apr 2005 (CEST)

Überarbeitung

Hallo zusammen! Ich bin heute morgen über das Chaos bei Datentyp/ADT/Datenstruktur usw. gestolpert ... Ich möchte mal einen Anstoß zum Neuordnen geben ... Was meint Ihr zu folgendem?

  1. Den Artikel Datentyp empfinde ich als Hauptpunkt, der auch weitgehend richtig ist, nur die Ordnung ist imho vollkommen durcheinander. Ich würde vorschlagen ihn als Übersichtsartikel umzuschreiben, sodass er mit kurzen Erklärungen auf folgende Unterartikel verweist, die dann den jetztigen Text zusammen mit einer vernünftigen Definition enthalten):
    1. Elementare Datentypen (dazu gehört meiner Ansicht nach -- zumindest nach meinem Sprachgebrauch -- alles was darunter aufgezählt wurde, also ordinale und nicht-ordinale Typen, sowie Zeichen
    2. zusammengesetzte Datentypen (könnte evtl. auch zu elem. Datentypen passen ???)
    3. Zeigertypen (könnte evtl. auch zu el. Datentypen passen ???)
    4. komplexe Datentypen/Datenstrukturen (Stacks, Queues usw.) ... das ist wohl vom Inhalt her das, was in Datenstrukturen zusammengefasst ist. Eigentlich ist dieser Punkt -- in meinem Verständnis -- kein Datentyp mehr, da ich von Datentypen als elementar spreche. Datenstrukturen ordnen Datentype dann in größeren Zusammenhängen an.
  2. Das beschreibt bisher, was ein Datentyp konkret ist, also wie er in Programmiersprachen auftaucht. Die zweite Frage stellt sich, wie man ihn abstrakt definiert. Dazu kann man sog. Abstrakte Datentypen verwenden. Sie definieren eine Menge von Werten, Operationen auf ihnen und eine zugehörige Semantik, die angibt, was die Operationen machen (siehe erster, unsignierter Beitrag auf Diskussion:Abstrakter Datentyp, nicht unbedingt der Inhalt von Abstrakter Datentyp). Dieses Konzept lässt sich nicht nur auf komplexe Datentypen/Datenstrukturen (im obigen Sinne) anwenden, sondern natürlich auch auf die elementaren Datentypen (int, string, float usw.). BTW: Weiß jemand eine Literaturstelle zum Begriff Signatur/Sorten? Mir ist der noch nie untergekommen, scheint aber mit ADT deckungsgleich. Insofern denke ich also, dass ADT eher als Methode zur Beschreibung zu verstehen ist und nicht als konkrete Implementation. Die Implementation ist vom ADT ja gerade unabhängig ... er beschreibt so zusagen nur die Schnittstelle!

Ich hoffe das ist nicht allzu wirr geraten ... Ich hoffe aiuf Antwort, Gruß --Jkrieger 11:28, 30. Jun 2005 (CEST)

Noch eine Anmerkung von mir zur Unterscheidung zwischen Datentyp und Datenstruktur. Zunächst mal sind Datenstrukturen immer deutlich komplexer als Datentypen. In der Regel handelt es sich eher um Klassen bzw. Objekttypen, wo also nicht nur Daten, sondern auch Operationen einen Rolle spielen. Ferner ist die Unterscheidung so ähnlich wie bei "Programmen" und "Algorithmen". Programme sind konkrete Implementationen von Algorithmen. Algorithmen selbst werden eher informal und sprachunabhängig beschrieben. Genauso sind Datentypen konkrete Realisierungen in einer Programmiersprache. Datenstrukturen werden hingegen eher informal und Sprachunabhängig beschrieben. Natürlich können Datenstrukturen auch implementiert werden und lassen sich dann als Objekt- oder Klassen-Typ betrachten, genauso wie Algorithmen implementiert werden können und sich dann als Programm betrachten lassen. Nur mal so als Anregung zur Unterscheidung. --Coma 1. Jul 2005 06:55 (CEST)
Nochwas: Das Wesen Abstrakter Datentypen/Datenstrukturen ist es bestimmte Dinge auszulassen. Meistens die Realisierung bestimmter Operationen nicht näher zu spezifizieren. Bei abstrakten Datentypen werden dann entsprechende Methoden nur angegeben, aber nicht implementiert (das ist dann Aufgabe von Ableitungen). Bei Datenstrukturen ist es ähnlich. Zum Beispiel spezifiziert ein Heap nur Operationen wie "insert" und "extractMin". Konkrete Realisierungen werden durch konkretere Datenstrkukturen wie Binären Heaps, Binomial-Heaps oder Fibonacci-Heaps beschrieben. Bei Datenstrukturen ist die Unterscheidung in "abstrakt" oder "nicht-abstrakt" aber schwieriger und Abhängig vom Standpunkt. Eine Datenstruktur B kann eine Datenstruktur A konkretisieren, und ist in diesem Sinne nicht abstrakt. Anderseits könnte B weitere Operatationen unspezifiziert lassen und in diesem Sinne abstrakt sein. Bei Datentypen würde man dann eindeutig von abstrakten Datentypen reden. Bei Datenstrukturen hängt es wie gesagt vom Standpunkt ab. Insofern sollte man nicht von abstrakten Datentypen reden, sondern immer nur sagen "B ist eine Konkretisierung von A". --Coma 1. Jul 2005 07:05 (CEST)
Darueber hatte mich mir bisher nie so konkret Gedanken gemacht. Ein guter Uebersichtsrtikel zu dem Thema waere super!
Ich schlage allerings vor noch mal etwas Abstand zu nehmen und noch ein bis zwei Ebenen darueber anzufangen. Das Chaos beginnt naemlich nicht erst bei Datentyp/Datenstrucktur sonder schon bei Datenverwaltung analog zu en:Data-Mangement. Also ich wuerde gerne ein durchdachtes Konzept auch fuer Datenformat, Dateiformat, Datentyp, Datenstruktur, etc. haben.
Gruss -- 1. Jul 2005 10:06 (CEST)^

Dann werde ich mal versuchen zusammenzufassen: In meiner obigen Auflistung ist der letzte Punkt komplexe Datentypen/Datenstrukturen dann wohl etwas blöd ... das hätte ich mir auch gleich überlegen können. Wie wäre es dann mit folgender Strukturierung (hab aber erst So abend wieder Zeit mich vernünftig mit dem Thema zu beschäftigen...):

  • Datentypen sind grundlegende Elemente, in denen Daten gespeichert werden (int, char, string, records/structs usw.). Auf ihnen sind nur elementare Operatione zwischen zwei Instanzen (also z.B. Addition zweier Zahlen) definiert. Wie die Daten im Speicher (oder whereever) tatsächlich abgelegt werden wäre dann das Datenformat (z.B. big-endian/little-endian, NULL-terminierter String usw.). Insofern wäre also ein Datentyp eine Abstrakte beschreibung, während das Datenformat die Implementation beschreibt.
  • Datenstrukturen sind dann komplexere Zusammenfassungen von mehreren Instanzen von Datentypen zu einer "Ordnung", auf der bestimmte Operationen definiert sind. Dabei kann es durchaus mehrere Datenstrukturen geben, die die selben Operationen auf unterschiedliche Art implementieren, aber immernoch das gleiche Interface haben.
  • Ein Abstrakter Datentyp (ADT) dient nun dazu vornehmlich Datenstrukturen zu beschreiben. Ein besserer Name wäre also Abstrakte Datenstruktur, heißt halt einfach anders ... Man kann dieses Konzept aber auch benutzen, um Datentypen zu beschreiben. In keinem Fall beschreibt ein ADT aber die konkrete Implementation, sondern immer nur die Mengen auf denen operiert wird und die Operationen!
  • Dateiformat wäre in dieser Hirarchie etwas ähnliches, wie ein Datenformat, allerdings fasst mehrere Instanzen von Datentypen zusammen zu einer größeren Struktur, die dann auf der Platte (oder wo auch immer ...) landet.

Noch offene Fragen:

  1. Wie würde man Datenbanken hier einfügen? Die sind ja mehr, als bloße Dateiformate ... oder sollte man die ganz woanders hinstellen?

Gruß, --Jkrieger 1. Jul 2005 14:44 (CEST)

Nachtrag: Den Begriff komplexe Datentypen würde ich dann eher ganz streichen ... --Jkrieger 1. Jul 2005 14:45 (CEST)

Hallo JKrieger, nur eine Antwort zur Frage nach den Datenbanken. Datenbanken sind eine Technologie zum Verwalten von Daten haben aber nichts mit Daten selbst zu tun. Gruss -- 3. Jul 2005 16:29 (CEST)

Ja, das stimmt schon ... insofern würden dann aber auch Datenstrukturen nicht hierher gehören, da die ja auch nur ein technoogie zur Verwaltung von Daten darstellen ... Ich dachte den Punkt etwas als Denkanstoß, da man ja z.B. auch ein Dateisystem schon als Datenbank auffassen kann ... und Dateiformate wurden hier ja auch schon vorgeschlagen ... Ich bin aber wirklich auch nicht ganz sicher, ob's wirklich hierher passt und auch kein Experte auf dem gebiet Datenbanken ... Gruß --Jkrieger 3. Jul 2005 20:54 (CEST)
Ich wuerde Datenstrukturen nicht als Technologie bezeichnen. Eine Technologie ist das Zusammenspiel verschiedener Techniken, eher sowas wie eine Loesung. Datenbanken enthalten Strukturen, Modelle, Sprachen, Algorithmen, etc. Am besten Du schaust Dir mal die Kategorie:Datenbank and, dann verstehst Du sicherlich, was ich meine. Gruss -- Sparti 3. Jul 2005 23:28 (CEST)

Beispiele

In welcher Sprache sind eigentlich die Beispiele notiert? --jpp 09:54, 25. Jul 2005 (CEST)

Das wollte ich auch grad fragen. :-) --RokerHRO 09:59, 9 November 2005 (CET)

Universeller Datentyp

Unter dem Lemma Universeller Datentyp (was ja als Weiterleitung vorerst hier auf diesen Artikel zeigen kann) sollten wohl mal all diese Datentypen zusammengefaßt werden, die umgangssprachlich auch als Allesfresser bezeichnet werden. Siehe auch:

  • C# mit „Object“
  • CLU mit „any“
  • VB mit „Variant“ (siehe auch Variant (Datentyp))
  • oder in Pascal, ich glaub da gab es auch mal so einen ähnlichen Datentyp

--Konrad – 16:12, 11. Nov. 2010 (CET)

Bitmengen

Bei der Aufzählung der elementaren Datentypen fehlt der Datentyp für Bitmengen (Schlüsselwort SET oder BITSET, siehe auch Menge_(Datenstruktur)). Dieser ist nicht zu verwechseln mit Aufzählungstypen oder Datenfeldern, da mehrere Elemente des Datentyps (respektive der Menge) gleichzeitig angesprochen werden können. In vielen Programmiersprachen werden ganzzahlige Datentypen für die Repräsentation von Bitmengen benutzt, was aber nichts an der Tatsache ändert, dass diese nichts miteinander zu tun haben (vergleiche auch Zuweisungskompatibilität#Mengen). Bautsch 11:37, 29. Apr. 2011 (CEST)

Datumsdatentypen

Es fehlt eine genauere Beschreibung von Datumsdatentypen, diese sind nur kurz in der Einleitung erwähnt. Ich hätte das jetzt bei den Elementaren Datentypen eingeordnet, bin mir jedoch nicht sicher und habe deshalb keine Änderung an dem Artikel vorgenommen. --17:41 29.11.2013 (CET) (ohne Benutzername signierter Beitrag von 91.49.52.156 (Diskussion))

Ein Datum (oder eine Uhrzeit) ist kein elementarer Datentyp, sondern es wird als Verbund gespeichert. --Bautsch (Diskussion) 16:41, 30. Nov. 2013 (CET)
Ich meine, da liegst du falsch: Ein Verbund ist eine Struktur, also eine beliebige Zusammenfassung anderer Datentypen inkl. (rekursiv enthaltener) anderer Verbünde. Die verschiedenen Datum-Datentypen sind m.E. numerische, sie gehören aber m.E. - siehe Artikel - zu den 'Konkreten Datentypen'. Ich denke, 'konkret' bedeutet hier 'eine konkretisierte Form' eines elementaren Tps, so wie z.B. auch eine Postleitzahl, eine Bankleitzahl, ein Kfz-Kennzeichen etc. Nur i.w.S. könnte man das als 'Verbund' sehen, da aber die Compiler solche Typen 'kennen' und auch funktional individuell behandeln, denke ich, dass das schon elementare DT sein müssten. Ich kenne mich da aber nicht wirklich exzellent aus. --VÖRBY (Diskussion) 17:12, 30. Nov. 2013 (CET)
Abgesehen von der konkreten Implementierung eines Datums als Julianisches Datum zum Beispiel als ganze Zahl werden in vielen Programmiersprachen Verbünde oder sogar Klassen verwendet, um Kalenderdaten zu speichern. Ein Verbund muss nicht notwendigerweise aus mehreren oder verschiedenen elementaren Datentypen bestehen und er muss auch nicht geschachtelt sein. --Bautsch (Diskussion) 21:25, 30. Nov. 2013 (CET)
Muss nicht, aber kann (mehrere, geschachtelt). Was heißt das nun bezüglich der sicher berechtigten Frage des IP-Users? Kann das jemand SICHER beantworten? --VÖRBY (Diskussion) 10:12, 1. Dez. 2013 (CET)
Sicher bin ich nicht, aber ich hätte mal so argumentiert:
  • Datums-/Zeittypen repräsentieren oft die Systemzeit, die z.B. in Sekunden seit 1. November 1970 (wenn ich mich nicht irre ... naja, halt seit einem fixen Datum) angegeben wird. Daraus kann dann das tatsächliche Datum in verschiedenen Datumssystemen abgeleitet/berechnet werden. So implementiert es z.B. die Klasse QDate in Qt (siehe qdatetime.h Zeile 137). Damit wäre der zugrundeliegende Datentyp eine Ganzzahl, also ein elementarer bzw. konkreter elementarer Datentyp.
  • Das gleiche gilt für time_t aus der C-standard lib: http://www.cplusplus.com/reference/ctime/time_t/
  • Auch in Origin (als Beispiel für wissenschaftliche Software) wird das Datum als numersicher Wert gespeichert und nur anders ANGEZEIGT: http://www.originlab.de/index.aspx?go=Products/Origin/DataManagement/WorkbooksAndWorksheets&pid=720
Hilft das weiter? --Jkrieger (Diskussion) 10:25, 1. Dez. 2013 (CET)
Nachtrag:
Schönen 1. Advent, --Jkrieger (Diskussion) 10:30, 1. Dez. 2013 (CET)
Sehe das auch so, dass das ein 'konkreter' Datentyp ist. Konkret und elementar sind dabei keine sich ausschließenden Begriffe, sondern ein konkreter DT basiert nur auf (zB) einem elementaren Typ. Wahrscheinlich gibt es auch andere konkrete DT, die vlt. auf Text, evtl. auch auf Verbund basieren. Nochmal zu 'Verbund', wenn jemand TTMMJJ etc im Quellcode als Verbund (bestehend aus diesen Elementen) definiert, dann ist das auch kein 'Datum' mehr, sondern es sind einfach mehrere 'Zahlen'.
Letzteres führt zu der Überlegung, aus welcher Sicht die DT klassifiziert werden: Ich denke das sind Ausdrücke aus der Syntax der Programmiersprache. Wenn man dort im Quellcode 'Datum' (mit Format) spezifiziert, dann behandelt der Compiler resp. das Laufzeitsystem Operationen auf diesem (deshalb konkreten) Datentyp. Ein manuell behandeltes Datum wäre also kein Datum-Datentyp mehr. --VÖRBY (Diskussion) 13:52, 1. Dez. 2013 (CET)
Da scheint einiges durcheinander zu gehen. Ein konkreter Datentyp ist das Gegenteil eines abstrakten Datentyps. Elementare Datentypen sind nie abstrakt, also immer konkret - aber nicht alle konkreten Datentypen sind elementar. Der Begriff konkreter Datentyp wird besonders dann relevant, wenn ein abstakter Datentyp, von dem es keine Instanzen geben kann, so erweitert wird (oft durch Vererbung), dass eine Instanz erzeugt werden kann (zum Beispiel mit einer new-Anweisung). Abstrakte Datentypen sind Ankerpunkte in Datenstrukturen, mit (imm konkret seienden) Instanzen können in Programmen dann die Daten verarbeitet werden. Ein Verbund kann sowohl konkret als auch abstrakt sein. Letzteres trifft zu, wenn ein Verbund als abstrakter Datentyp in einer Datenstruktur definiert wird, der zur Benutzung in Instanzen erweitert werden muss (in Java wäre das zum Beispiel eine Klasse ohne Instanzvariablen und Methoden). Auch konkrete Datentypen können gegebenenfalls erweitert werden. Programme oder Programmiersprachen ohne Vererbung kennen in der Regel nur konkrete Datentypen. Beispiel Fahrzeug, mit diesem abstrakten Datentyp kann man in einem Programm keine Operationen durchführen, da gar keine Daten vorhanden sind:
Abstrakter Datentyp Fahrzeug

Konkreter Datentyp Seefahrzeug ist ein Fahrzeug mit elementarem Datentyp REAL t = Tiefgang in Metern

Konkreter Datentyp Landfahrzeug ist ein Fahrzeug mit elementarem Datentyp INTEGER n = Anzahl Räder

Konkreter Datentyp Straßenfahrzeug ist ein Landfahrzeug mit elementarem Datentyp REAL r = engstem Kurvenradius in Metern

Konkreter Datentyp Schienenfahrzeug ist ein Landfahrzeug mit elementarem Datentyp REAL s = Spurweite in Metern
--Bautsch (Diskussion) 14:13, 3. Dez. 2013 (CET)

Hallo zusammen. Hab nochmal gegoogelt. Die gefundenen Quellen definieren 'abstrakt' meist als programmiersprachenunabhängig, während 'konkret' sprachenabhängig sei. Bautsch, bei dir scheint im Gegensatz dazu das Instanziieren/Vererben ... eine Rolle zu spielen. Dazu merke ich nur an: Das kann aber nur für Sprachen gelten, die sowas überhaupt kennen. Z.B. bei ASS/Cobol und Konsorten (frühe Sprachen) gibt/gab es sowas nicht, und damit vlt. auch nicht diese beiden Begriffe?
Da ich im Thema wirklich nicht DER Spezialist bin, will mich deshalb hier verabschieden. Sorry für die Einmischung, ich hatte meine Meinung aus der Artikeleinleitung abgeleitet. Zur Frage des IP-Users zu Datumsfeldern wäre aber die Antwort noch offen, ebenfalls die Erklärung von 'konkreter Datentyp'. Meine Meinung zu Datum = Verbund bleibt aber bestehen.--VÖRBY (Diskussion) 17:19, 3. Dez. 2013 (CET)

Hhmmm ... Ich glaube auch hier geht es nicht um abstrakte Klassen und instanziierbare Klassen (dafür habe ich den begriff konkret noch nie gehört). Ich habe konkret nicht weiter nachgeschlagen, sondern die implizite Definition eines vorredners benutzt, also: ein elementarer Datentyp, der ein "konkretes" Objekt aus der realen Welt (über Zahlen etz. hinaus), also etwa eine ISBN-Nummer (String), ein Datum (int), eine Postleitzahl (int) darstellt. Das hat natürlich auch nix mit der Def im ARtikel zu tun.
Ich glaube mit dem konkret führen wir uns (die Anfangsfrage betreffend) in die Irre ... Wir sollten uns wieder dem Datum zuwenden ... IMHO wird dafür meißt ein Integer verwendet, der mit einem gegebenen Intervall ab einem gegebenem Start zählt. Natürlich KANN man das auch als Verbund aus Tag/Monat/Jahr/Stunden/Minuten/Sekunden/... definieren ... aber macht das irgendjemand? Alle Funde, die ich oben aufgezählt haben, nutzen intern einfach einen int ...
Schönen Abend, --Jkrieger (Diskussion) 18:37, 3. Dez. 2013 (CET)
In der Tat, in "früheren" Programmiersprachen wie FORTRAN, C, Pascal oder BASIC gibt es keine abstrakten, sondern nur konkrete Datentypen. Einige elementare und somit auch konkrete Datentypen sind in Programmiersprachen schon vorimplementiert und können einfach verwendet werden - manchmal ein paar weniger, und manchmal auch ein paar mehr - und das hängt insofern von der verwendeten Programmiersprache ab. Abstrakte Datentypen (die Klasse "Object" in Java möge als Beispiel für eine Ausnahme von dieser Regel dienen) sind nicht in einer Programmiersprache definiert, sondern müssen mit Hilfe einer geeigneten Programmiersprache formuliert respektive definiert werden (und das sind in der Regel objektorientierte Programmiersprachen). --Bautsch (Diskussion) 18:46, 3. Dez. 2013 (CET)
Ich glaube wir meinen alle das gleiche, nur mit unterschiedlichen Worten! Also bleibt noch die EIGENTLICHE FRAGE zu beatworten: Was für ein Datentyp ist ein Datum (typischerweise)? Bzw.: Wie wird ein Datumsdatentyp üblicherweise dargestellt/implementiert? --Jkrieger (Diskussion) 20:03, 3. Dez. 2013 (CET)
Es gibt keine typische Darstellung. In Java wird das Datum oft mit einer Instanz der Standard-Klasse Date verarbeitet: Date in Java. Im einfachsten Fall wird es zusammen mit der Uhrzeit als ganze Zahl repräsentiert und entsprechend berechnet, meist aus der Zahl der Millisekunden seit dem 1. Januar 1970, die in der Informationstechnologie allgemein auch als Systemzeit bezeichnet wird: System time. In vielen Fällen wird ein Verbund mit drei elementaren ganzzahligen Datentypen (für den Tag, den Monat und das Jahr) verwendet: A Description of the Oberon-2 Language - Types. --Bautsch (Diskussion) 09:38, 4. Dez. 2013 (CET)
Ich denke schon, dass man von einer typischen Darstellung sprechen kann. Ich würde mal behaupten die meisten Bibliotheken werden eine interne Darstellung als int nutzen ... das Oberon Beispiel ist ja kein "offizieller" Datumstyp des Sprachstandards, sondern ein Beispiel für ein record/struct. Man sollte wohl Beides im Artikel darstellen, etwa so:
Datumstypen werden oft als Uminterpretation eines ganzzahligen elementaren Datentyps implementiert. Das Datum ist dann z.B. in Millisekunden seit dem 1.1.1970 gespeichert und kann davon ausgehend in jede andere Form überführt werden. Genausogut kann ein Datum natürlich auch als Verbund (z.B. aus drei Zahlen für Tag, Monat und jahr) dargestellt werden.
Beim ersten Satz könnte man dann z.B. auf den C-Sprachstandard (siehe C-Standard, S. 338) und ein oder zwei der Links oben als Beleg verweisen. Passt das allen? --Jkrieger (Diskussion) 09:56, 4. Dez. 2013 (CET)
Finde ich textlich ok; statt 'Uminterpretation' vlt. 'als individuelle und zusätzliche Formatfestlegung'. Das sollte bei 'Datentypen in Programmiersprachen' (das sind also durchwegs 'konkrete Datentypen!), vielleicht am Ende mit 'Individuelle Formatierungen' angefügt werden. Im Verbundbeispiel könnte man sogar auch 'Text' als Beispiel verwenden. Danke für die konstruktiven Beiträge. --VÖRBY (Diskussion) 13:00, 4. Dez. 2013 (CET)

Defekte Weblinks

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
  • Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks.
  • Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

– GiftBot (Diskussion) 05:26, 27. Nov. 2015 (CET)

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