Privacy Policy Cookie Policy Terms and Conditions Diskussion:Datentyp - Wikipedia

Diskussion:Datentyp

aus Wikipedia, der freien Enzyklopädie

Inhaltsverzeichnis

[Bearbeiten] 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)


[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] "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)

[Bearbeiten] Ü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)

[Bearbeiten] 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)
THIS WEB:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2006:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu