编程语言的德语介绍.doc

Programmiersprachen Programm = Text mit Anweisungen fr einen Computer; Widersprchliche Anforderungen an Formulierung eines Programms: Soll einerseits fr den Menschen lesbar sein, andererseits von einer Maschine verarbeitbar; Anforderungen fr Lesbarkeit durch Menschen: o nahe an gewohnter Umgangssprache (z.B. Englisch), o bersichtliche Struktur, o kompakte Notation, o etc. Anforderungen fr Ausfhrbarkeit durch Maschinen: o przise und eindeutig, o leicht in Strukturen der Maschine umsetzbar, o etc. Ergebnis: Programmiersprachen mit folgenden Eigenschaften o Umgangssprachliche Komponenten (Wrter wie if, while und main), o Notation teilweise angelehnt an mathematische Schreibweise, o Gliederung in Zeilen mit Einrckung, o formale Syntax, d.h. kein Auslegungsspielraum o maschinen-nahe Grundbausteine (ganze Zahlen) 2.1 Generationen Programmiersprachen haben sich ber mehrere Generationen hinweg entwickelt: Maschinensprachen (1. Generation) Die Sprachen der 1. Generation sind Maschinensprachen, deren Elemente direkt aus dem Befehlsvorrat bestimmter Computer abgeleitet sind. Maschinensprache ist spezifisch fr genau einen Prozessor und ein Betriebssystem und damit in hchstem Mae unportabel. Maschinenprogramme werden heute nicht mehr direkt geschrieben. Assemblersprachen (2. Generation) Assemblersprachen, in denen Maschinenbefehle durch leichter lesbare Abkrzungen ersetzt sind. Immer noch diktiert die Zielmaschine die Struktur der Sprache. Assemblerprogramme werden heute nur noch dann geschrieben, wenn es aus zwingenden Grnden notwendig ist. Hhere Programmiersprachen (3. Generation) Sprachen der 3. Generation (auch genannt hhere Programmiersprachen oder problemorientierte Programmiersprachen) orientieren sich an den zu lsenden Problemen und nicht mehr an den benutzten Maschinen. Die meisten zeitgemen Programmiersprachen fallen in diese Kategorie. Dazu zhlen C und C+, die Programmiersprachen, die in dieser Vorlesung gelehrt wird. Spezialsprachen (4., 5. Generation?) Schlielich werden manche Sprachen einer 4. oder 5. Generation zugeordnet. Diese Sprachen sind auf bestimmte Anwendungen und Problemklassen zugeschnitten und knnen nicht mehr als general purpose languages bezeichnet werden. 2.2 Eigenschaften von Programmiersprachen Eigenschaften von Programmiersprachen werden auf verschiedenen Ebenen festgelegt; Syntax Die Syntax regelt die Rechtschreibung einer Programmiersprache. Sie lt sich formal festlegen, z.B. mit Syntaxdiagrammen oder in einer Grammatik. Semantik Die Semantik regelt die Bedeutung einzelner Sprachelemente und ihr Zusammenspiel. Sie lt sich viel schwieriger exakt festhalten. Die meisten Versuche, Semantik formal zu fixieren, mndeten bisher in schwer lesbaren oder sehr umfangreichen Beschreibungen. Unabhngig von der Beschreibung ist das Thema Semantik noch wesentlich komplexer als hier angedeutet. So gibt es z.B. eine statische und eine dynamische Semantik, von denen erstere bis zu einem gewissen Grad automatisch berprft werden kann, whrend letztere erst zur Laufzeit zum Tragen kommt. Pragmatik Die Pragmatik beschreibt Einschrnkungen und Randbedingungen, die sich aus konkreten Implementierungen heraus ergeben. Die Grenzen zwischen Syntax und Semantik, sowie zwischen Semantik und Pragmatik sind verschwommen und lassen sich nicht eindeutig ziehen. 2.3 Formalismen zur Beschreibung der Syntax Zur Definition der exakten Syntax von Programmiersprachen kommen verschiedene Hilfsmittel zum Einsatz. Die beiden wichtigsten (Syntaxdiagrammen und Grammatiken) werden hier gezeigt. 2.3.1 Syntaxdiagramme Syntaxdiagramme sind halbgraphische Dastellungen, die gegenber Grammatiken bersichtlicher und leichter lesbar sind. Aufbau Einzeldiagramme Um die Syntax einer Sprache mit einem Syntaxdiagramm zu beschreiben, werden mehrere Einzeldiagramme verwendet. Das dient der bersichtlichkeit, ist aber aus rein formaler Sicht nicht zwingend notwendig. Alle Einzeldiagramme zusammen bilden ein komplettes Syntaxdiagramm. Jedes Einzeldiagramm hat einen eindeutigen Namen. Pfeile Jedes Einzeldiagramm enthlt Knoten, die mit Pfeilen verbunden sind. Die Pfeile regeln die Abfolge der Knoten. Pfeile knnen sich innerhalb eines Einzeldiagramms gabeln und zusammengefhrt werden. Terminale Knoten Knoten werden als Ksten gezeichnet. Es gibt zwei Arten von Knoten: terminale und nichtterminale Knoten. Terminale Knoten enthalten wrtlich zu nehmende Texte. Sie werden durch Kreise, Ovale oder Ksten mit abgerundeten Ecken dargestellt. Nichtterminale Knoten Nichtterminale Knoten benennen ein anderes Einzeldiagramm, das an dieser Stelle durchlaufen werden mu. Nichtterminale Knoten werden durch Ksten mit normalen Ecken dargestellt. Man kann sich vorstellen, da das benannte Einzeldiagramm anstelle des nichtterminalen Knotens eingehngt wird. Anwendung Ein Text ist (im Sinne des Syntaxdiagrammes) korrekt, wenn er mit einem kompletten Durchlauf des Syntaxdiagrammes vollstndig nachvollzogen werden kann. Dabei darf am Ende weder ein Rest des Textes noch ein Rest des Syntaxdiagrammes unverarbeitet brigbleiben. Es kommt nur darauf an, da es irgendeinen Weg durch das Syntaxdiagramm gibt, der zum Text pat. Es spielt keine Rolle, welche Abzweigungen dabei genommen werden. Beispiel Das folgende Beispiel zeigt das Syntaxdiagramm zur Beschreibung der Syntax von ganzen Zahlen in C: Die Zeichenfolge +230859 entspricht z.B. dem Syntaxdiagramm, die Zeichenfolge 3.141592 dagegen nicht. 2.3.2 Grammatik in EBNF Grammatiken werden in unterschiedlichen Notationen formuliert. Eine sehr verbreitete Notation ist die EBNF (= Erweiterte Backus-Naur Form). Die EBNF ist gegenber Syntaxdiagrammen kompakter und als reine Textdarstellung leichter maschinell zu verarbeiten. Seltener verwendet wird die ursprngliche, einfache BNF (= Backus-Naur Form). Dieser fehlen gegenber der EBNF ein paar bequeme, abkrzende Schreibweisen; mit beiden Formen lassen sich aber dieselben Grammatiken wiedergeben. Zusammenhang mit Syntaxdiagrammen Mit einer Grammatik in EBNF wird die korrekte Syntax einer formalen Sprache beschrieben, genauso wie mit Syntaxdiagrammen. Im Gegensatz zu Syntaxdiagrammen erlaubt eine EBNF nicht alle Verbindungen und erzwingt damit strengere Auflagen. Das Ergebnis sind zwangslufig besser strukturierte Grammatiken. Demnach kann zwar jede EBNF als Syntaxdiagramm formuliert werden, das Umgekehrte gilt nicht in jedem Fall. Aufbau und Metasyntax Produktionen Eine EBNF besteht aus einer Liste von Produktionen. Jede Produktion beschreibt die Syntax eines bestimmten Grammatikfragmentes. Produktionen werden als eine Art Gleichungen geschrieben. Auf der linken Seite steht ein Name fr das definierte Grammatikfragment; auf der rechten Seite steht eine Folge von Symbolen, die den Aufbau des Grammatikfragmentes festlegen. Zwischen linker und rechter Seite wird das Trennzeichen := gesetzt. Das Ende einer Produktion wird mit einem Punkt gekennzeichnet, also schematisch: linke Seite := rechte Seite .Terminale und Nichtterminale Von den Symbolen, die auf der rechten Seite einer Produktion vorkommen, gibt es zwei Arten: Die Terminale stehen fr sich selbst, sie sind wrtlich zu nehmen. Die Nichtterminale benennen eine andere Produktion, die an dieser Stelle einzusetzen ist. Zur Unterscheidung werden Terminale oft in Gnsefchen gesetzt, Nichtterminale unterstrichen oder einfach berhaupt nicht markiert. Optionale Symbolfolgen Um eine Reihe von Symbolen auf der rechten Seite einer Produktion als optional zu kennzeichnen, wird diese in eckige Klammern gesetzt. Wiederholbare Symbolfolgen Eine Symbolfolge wird in geschweifte Klammern gesetzt, wenn sie beliebig oft wiederholt werden darf. Das schliet Weglassen, d.h. null-maliges Wiederholen, mit ein. Das Beispiel fr Syntaxdiagramme als EBNF: integer := sign digit digit.In diesem Zusammenhang ist eine alternative Notation blich, die in der EBNF eigentlich nicht vorgesehen ist: Hinter die geschweifte Klammer kann auch ein Plus-Zeichen gesetzt werden, um ein- oder mehrmalige Wiederholung auszudrcken. Das obige Beispiel wrde dann krzer lauten: integer := sign digit+.Um die ursprngliche, beliebige Wiederholung davon klar abzuheben, wird diese dann ausdrcklich mit einem Stern nach der geschweiften Klammer markiert. Die folgende Schreibweise ist umstndlicher, aber inhaltlich gleichwertig mit der vorhergehenden: integer := sign digit digit*.Alternativen Wenn mehrere Symbolfolgen auf der rechten Seite einer Produktion zur Auswahl stehen, werden die Mglichkeiten nacheinander aufgefhrt und mit senkrechten Strichen getrennt. Das folgende Beispiel zeigt die komplette EBNF fr eine integer-Konstante in C-Syntax: integer := sign digit digit.sign := + | -.digit := 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9.Gruppierung Symbolfolgen knnen mit einfachen runden Klammern gruppiert werden, um Alternativen einzugrenzen. Auch die anderen Klammer-Arten (eckige und geschweifte) knnen so benutzt werden. Das folgende Beispiel ist zwar ungeschickt, illustriert aber diese Mglichkeit: integer := sign(0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9)digit.sign := + | -.digit := 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9.Metasyntax Die EBNF folgt einer eigenen Syntax, die mit der durch die EBNF beschriebenen Syntax nichts zu tun hat. Man nennt die EBNF-eigene Syntax ihre Metasyntax. Die Metasyntax der EBNF kann fast in ihrem eigenen Formalismus beschrieben werden: ebnf := duction := leftside := rightside .leftside := nonterminal.rightside := alternative | alternative.alternative := sequence.sequence := rightside | rightside |( rightside ) |symbol.symbol := terminal | nonterminal.terminal := doublequote text doublequote.nonterminal := identifier.identifier := letter letter | digit.Die folgenden Nichtterminale sind nicht mehr aufgelst: letter steht fr einen Buchstaben; digit steht fr eine Ziffer; text steht fr eine Folge von beliebigen Zeichen auer Gnsefchen; doublequote steht fr das Terminal mit Gnsefchen als Inhalt; Beispiel Dateispezifikation Die folgende EBNF beschreibt die Syntax eines Pfadnamens einer Datei, wie er von vielen Unix-Kommandos erwartet wird: filespec := root dirspec name.root := /.dirspec := (name | . | .) /.name := char+.char := letter | digit | _ | + | - | :.Anmerkung: Die konkrete Auswahl der in Dateinamen zulssigen Sonderzeichen hngt von der Shell und deren Konfiguration ab. Syntax von C Die komplette Syntax von C in EBNF-Notation finden Sie z.B. in KR. 2.4 C und C+ 2.4.1 Historische Entwicklung Diese Vorlesung fhrt die Programmiersprachen C und C+ ein, die beide zu den hheren Programmiersprachen (im Sinne der obigen Klassifizierung) zhlen. C hat sich ursprnglich einen Namen als Sprache zur Systemprogrammierung gemacht (Implementierung von Unix). Ein erster Meilenstein in der Entwicklung von C war 1983 die Verffentlichung des Buches The C Programming Language (Kernighan/Ritchie), das fr Jahre eine Art Pseudo-Standard festlegte. Mit ANSI-C wurde die Sprache 1988 offiziell standardisiert, so da heute praktisch alle C-Compiler den gleichen Sprachumfang beherrschen. C ist seiner Art nach eine Programmiersprache aus der ra der strukturierten Programmierung, wie auch Pascal, Modula, u.a. C+ wurde als Nachfolger von C geschaffen mit dem erklrten Ziel objektorientierte Programmierung zu erschlieen. Wie bei C machte C+ einige Entwicklungsstufen durch, von denen eine erste 1990 mit der Verffentlichung des Buches The Annotated C+ Reference Manual (Ellis/Stroustrup) (the ARM) markiert wird. 1995 wurde der Draft-Standard fr ANSI-C+ verabschiedet. Dieses Dokument ist zwar noch keine endgltige Sprachnorm, tiefgreifende nderungen sind aber nicht mehr zu erwarten. C+ ist eine objektorientierte Programmiersprache, die weitgehend aufwrtskompatibel zu C bleibt (d.h. da C-Programme mit wenigen Modifikationen auch von C+-Compilern akzeptiert werden). 2.4.2 Einsatz in der Vorlesung Die ersten Themen der Vorlesung sind neutral gegenber C und C+. Mit I/O, homogenen und heterogenen zusammengesetzten Datenstrukturen (Strings, Vektoren und Strukturen bzw. Klassen) werden aber Themen erreicht, die sich in C+ wesentlich sicherer und eleganter behandeln lassen. Ab hier orientiert sich die Vorlesung an C+. Erst in der Nachfolgeveranstaltung Programmieren II kehren wir zu C zurck. Zu diesem Zeitpunkt haben Sie die notwendigen Vorkenntnisse, um die inneren Ablufe von C nachvollziehen zu knnen. Diese sind letztlich auch fr C+ mageblich, werden dort aber gut abgeschirmt. Alle Ausfhrungen beziehen sich zunchst auf ANSI-C. Sofern Spracheigenschaften besprochen werden, die nur in ANSI-C+ (aber nicht in ANSI-C) erlaubt sind, weist diese Markierung darauf hin. Whrend die Syntax der Sprachen nicht allzu schwer zu erlernen ist, sind die Kenntnis der Semantik und Pragmatik von C(+) eines der wesentlichen Lernziele dieser Vorlesung. Die Syntax von C(+) lt sich in einer Grammatik festschreiben, die z.B. in der EBNF verfat sein kann. Die Semantik ist meist umgangssprachlich beschrieben und macht den grten Teil des Inhaltes der weitverbreiteten Literatur aus. Ein Beispiel fr die Semantik ist z.B. die Forderung, da jeder Bezeichner definiert bzw. deklariert sein mu, bevor er verwendet werden kann. Die Pragmatik der Sprachen findet sich oft in der Dokumentation von einzelnen Implementierungen, wie z.B. Compiler-Handbchern oder Release Notes. Ein Beispiel fr die Pragmatik ist die Begrenzung des Wertebereiches des Datentyps int, die von bestimmten Rechnerarchitekturen auferlegt wird. 2.5 bersetzen und Ausfhren von Programmen Ungeachtet aller hheren Programmiersprachen knnen Computer nur Maschinenprogramme ausfhren. Alle anderen Sprachen mssen erst in ein Maschinenprogramm umgeformt (bersetzt) werden, bevor sie ausgefhrt werden knnen. Diese bersetzung ist bei Sprachen wie C oder C+ verhltnismig aufwendig. Sie lt sich nicht mit vertretbarem Aufwand von Hand erledigen. Statt dessen werden die Sprachen mit spezialisierten Hilfsprogrammen, sogenannten bersetzern oder Compilern, automatisch in Maschinensprache transformiert. Compiler sind selbst sehr komplexe Programme, deren Konstruktion ein eigenes Lehrgebiet ausmacht. Programm-Text wird Quelltext genannt (engl. source) und ist, fr sich gesehen, nichts anderes als lesbarer Klartext. Das vom Compiler aus dem Quelltext automatisch produzierte und dann ausfhrbare Maschinenprogramm heit bersetztes Programm oder Binrprogramm (engl. binary oder executable). Der Begriff des Programms wird sowohl fr Quelltext, wie auch fr bersetzte Programme benutzt. Ein Binrprogramm ist nicht mehr lesbar und i.d.R. wesentlich umfangreicher als der ursprngliche Quelltext. Soweit der Compiler fehlerfrei arbeitet, verhlt sich das Binrprogramm genau so, wie es im Quelltext beschrieben steht. (Da sich das nicht immer mit den Vorstellungen des Programmierers deckt, ist eine andere Sache.) Compiler erwarten kompletten und korrekten Quelltext, bevor sie ein Binrprogramm produzieren knnen. Bei umfangreichen Quelltexten wird die fr die bersetzung aufzuwendende Zeit sprbar, so da Interpreter entwickelt wurden. Interpreter verlangen keinen kompletten Quelltext, sondern lesen Quelltext Schritt fr Schritt und fhren jeden gelesenen Schritt sofort aus. Damit kann z.B. der Anfang eines Programms schon ausprobiert werden, bevor das Ende berhaupt fertig ist. Der Preis fr diese gewonnene Flexibilitt ist gegenber einem Binrprogramm reduzierte Ablaufgeschwindigkeit, weil Compiler Informationen aus dem gesamten Programm fr Optimierungen verwenden knnen. Darber hinaus eignen sich nicht alle Programmiersprachen (zu ihnen zhlen auch C und C+) von ihrem Aufbau her fr schrittweise Ausfhrung, weil sich z.B. Programmteile an weit auseinander liegenden Stellen gegenseitig beeinfluen. Diese Skizze zeigt schematisch die Entwicklung eines Programmes: (Schraffierte Ksten sind ausfhrbare Programme, Ksten ohne Schraffur sind Daten;) 2.6 Programm-Quelltext Der Quelltext eines C(+)-Programm wird zunchst als Text geschrieben. Dabei sind einige allgemeine Regeln zu beachten: 2.6.1 Zwischenrume und Leerzeilen Unter dem Begriff Zwischenraum werden blicherweise Folgen bestimmter Kontrollzeichen verstanden: Leerzeichen (Space oder Blank), Tabulator (Tab) Zeilenwechsel (Return oder Enter) Zwischenrume werden benutzt, um Quelltext optisch (d.h. fr den menschlichen Leser bersichtlich) zu gliedern. Das Gesamt-Arrangement (Wort-Abstand, Einrckung, Leerzeilen) wird unter dem Begriff Layout zusammengefat. Notwendig aus der Sicht von C(+) ist Zwischenraum nur an wenigen, seltenen Stellen. berspitzt formuliert: Der Compiler ignoriert das Layout (weitgehend). Es spielt keine Rolle, wie viel Zwischenraum eingeschoben wird. Ein einzelnes Leerzeichen ist gleichwertig mit eintausend Leerzeilen. Die Entwicklung eines persnlichen Programmierstils schlgt sich zu einem guten Teil in einem einheitlichen Layout nieder. Dabei wird allgemein anerkannt, da die konkrete Art des persnlichen Stils eine untergeordnete Rolle spielt, wenn er nur konsequent durchgehalten wird. 2.6.2 Gro- und Kleinschreibung Groe und kleine Buchstaben werden von C(+) i.allg. als unterschiedlich b