编程语言的德语介绍

Programmiersprachen

•

•

Programm = Text mit Anweisungen für einen Computer;

Widersprüchliche Anforderungen an Formulierung eines Programms: Soll einerseits

für den Menschen lesbar sein, andererseits von einer Maschine verarbeitbar;

Anforderungen für Lesbarkeit durch Menschen:

o

nahe an gewohnter Umgangssprache (z.B. Englisch),

o

übersichtliche Struktur,

o

kompakte Notation,

o

etc.

•

•

Anforderungen für Ausführbarkeit durch Maschinen:

o

präzise und eindeutig,

o

leicht in Strukturen der Maschine umsetzbar,

o

etc.

•

Ergebnis: Programmiersprachen mit folgenden Eigenschaften

o

Umgangssprachliche Komponenten (Wörter wie "if", "while" und "main"),

o

Notation teilweise angelehnt an mathematische Schreibweise,

o

Gliederung in Zeilen mit Einrückung,

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 für

genau einen Prozessor und ein Betriebssystem und damit in höchstem Maße unportabel.

Maschinenprogramme werden heute nicht mehr direkt geschrieben.

Assemblersprachen (2. Generation)

Assemblersprachen, in denen Maschinenbefehle durch leichter lesbare Abkürzungen ersetzt

sind. Immer noch diktiert die Zielmaschine die Struktur der Sprache. Assemblerprogramme

werden heute nur noch dann geschrieben, wenn es aus zwingenden Gründen notwendig ist.

Höhere Programmiersprachen (3. Generation)

Sprachen der 3. Generation (auch genannt "höhere Programmiersprachen" oder

"problemorientierte Programmiersprachen") orientieren sich an den zu lösenden Problemen

und nicht mehr an den benutzten Maschinen. Die meisten zeitgemäßen

Programmiersprachen fallen in diese Kategorie. Dazu zählen "C" und "C++", die

Programmiersprachen, die in dieser Vorlesung gelehrt wird.

Spezialsprachen (4., 5. Generation?)

Schließlich werden manche Sprachen einer 4. oder 5. Generation zugeordnet. Diese

Sprachen sind auf bestimmte Anwendungen und Problemklassen zugeschnitten und können

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 läßt sich formal

festlegen, z.B. mit Syntaxdiagrammen oder in einer Grammatik.

Semantik

Die Semantik regelt die Bedeutung einzelner Sprachelemente und ihr Zusammenspiel. Sie

läßt sich viel schwieriger exakt festhalten. Die meisten Versuche, Semantik formal zu fixieren,

mündeten bisher in schwer lesbaren oder sehr umfangreichen Beschreibungen. Unabhängig

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 überprüft werden kann, während letztere erst zur

Laufzeit zum Tragen kommt.

Pragmatik

Die Pragmatik beschreibt Einschränkungen 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 gegenüber Grammatiken

übersichtlicher und leichter lesbar sind.

2.3.1.1 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 enthält Knoten, die mit Pfeilen verbunden sind. Die Pfeile regeln die

Abfolge der Knoten. Pfeile können sich innerhalb eines Einzeldiagramms gabeln und

zusammengeführt werden.

Terminale Knoten

Knoten werden als Kästen gezeichnet. Es gibt zwei Arten von Knoten: terminale und

nichtterminale Knoten. Terminale Knoten enthalten wörtlich zu nehmende Texte. Sie

werden durch Kreise, Ovale oder Kästen mit abgerundeten Ecken dargestellt.

Nichtterminale Knoten

Nichtterminale Knoten benennen ein anderes Einzeldiagramm, das an dieser Stelle

durchlaufen werden muß. Nichtterminale Knoten werden durch Kästen mit normalen Ecken

dargestellt. Man kann sich vorstellen, daß das benannte Einzeldiagramm anstelle des

nichtterminalen Knotens eingehängt wird.

2.3.1.2 Anwendung

Ein Text ist (im Sinne des Syntaxdiagrammes) korrekt, wenn er mit einem kompletten

Durchlauf des Syntaxdiagrammes vollständig 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 paßt. Es spielt keine Rolle, welche Abzweigungen dabei genommen werden.

2.3.1.3 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 gegenüber

Syntaxdiagrammen kompakter und als reine Textdarstellung leichter maschinell zu

verarbeiten.

Seltener verwendet wird die ursprüngliche, einfache "BNF" (= "Backus-Naur Form"). Dieser

fehlen gegenüber der EBNF ein paar bequeme, abkürzende Schreibweisen; mit beiden

Formen lassen sich aber dieselben Grammatiken wiedergeben.

2.3.2.1 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 zwangsläufig besser strukturierte Grammatiken.

Demnach kann zwar jede EBNF als Syntaxdiagramm formuliert werden, das Umgekehrte gilt

nicht in jedem Fall.

2.3.2.2 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 für 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 für sich selbst, sie sind wörtlich zu nehmen.

Die Nichtterminale benennen eine andere Produktion, die an dieser Stelle

einzusetzen ist.

Zur Unterscheidung werden Terminale oft in Gänsefüßchen 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 schließt Weglassen, d.h. null-maliges Wiederholen, mit ein. Das Beispiel für

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 auszudrücken. Das obige Beispiel würde

dann kürzer lauten:

integer ::= [sign] {digit}+.

Um die ursprüngliche, beliebige Wiederholung davon klar abzuheben, wird diese dann

ausdrücklich mit einem Stern nach der geschweiften Klammer markiert. Die folgende

Schreibweise ist umständlicher, 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 Möglichkeiten nacheinander aufgeführt und mit senkrechten Strichen getrennt.

Das folgende Beispiel zeigt die komplette EBNF für eine integer-Konstante in "C"-Syntax:

integer ::= [sign] digit {digit}.

sign ::= "+" | "-".

digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9".

Gruppierung

Symbolfolgen können mit einfachen runden Klammern gruppiert werden, um Alternativen

einzugrenzen. Auch die anderen Klammer-Arten (eckige und geschweifte) können so benutzt

werden. Das folgende Beispiel ist zwar ungeschickt, illustriert aber diese Möglichkeit:

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 ::= {production}.

production ::= 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 aufgelöst:

•

•

•

•

letter steht für einen Buchstaben;

digit steht für eine Ziffer;

text steht für eine Folge von beliebigen Zeichen außer Gänsefüßchen;

doublequote steht für das Terminal mit Gänsefüßchen als Inhalt;

2.3.2.3 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 zulässigen Sonderzeichen hängt von

der Shell und deren Konfiguration ab.

2.3.2.4 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 führt die Programmiersprachen "C" und "C++" ein, die beide zu den

höheren Programmiersprachen (im Sinne der obigen Klassifizierung) zählen.

"C" hat sich ursprünglich einen Namen als Sprache zur Systemprogrammierung gemacht

(Implementierung von "Unix"). Ein erster Meilenstein in der Entwicklung von "C" war 1983

die Veröffentlichung des Buches "The C Programming Language" (Kernighan/Ritchie), das

für 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 erklärten Ziel objektorientierte

Programmierung zu erschließen. Wie bei "C" machte "C++" einige Entwicklungsstufen durch,

von denen eine erste 1990 mit der Veröffentlichung des Buches "The Annotated C++

Reference Manual" (Ellis/Stroustrup) ("the ARM") markiert wird. 1995 wurde der Draft-Standard für "ANSI-C++" verabschiedet. Dieses Dokument ist zwar noch keine endgültige

Sprachnorm, tiefgreifende Änderungen sind aber nicht mehr zu erwarten.

"C++" ist eine objektorientierte Programmiersprache, die weitgehend aufwärtskompatibel

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 gegenüber "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" zurück. Zu diesem

Zeitpunkt haben Sie die notwendigen Vorkenntnisse, um die inneren Abläufe von "C"

nachvollziehen zu können. Diese sind letztlich auch für "C++" maßgeblich, werden dort aber

gut abgeschirmt.

Alle Ausführungen beziehen sich zunächst auf ANSI-C. Sofern Spracheigenschaften

besprochen werden, die nur in ANSI-C++ (aber nicht in ANSI-C) erlaubt sind, weist diese

Markierung darauf hin.

Während 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(++) läßt sich in einer Grammatik festschreiben, die z.B. in der EBNF verfaßt

sein kann.

Die Semantik ist meist umgangssprachlich beschrieben und macht den größten Teil des

Inhaltes der weitverbreiteten Literatur aus. Ein Beispiel für 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-Handbüchern oder "Release Notes". Ein Beispiel für

die Pragmatik ist die Begrenzung des Wertebereiches des Datentyps int, die von bestimmten

Rechnerarchitekturen auferlegt wird.

2.5 Übersetzen und Ausführen von Programmen

Ungeachtet aller höheren Programmiersprachen können Computer nur

Maschinenprogramme ausführen. Alle anderen Sprachen müssen erst in ein

Maschinenprogramm umgeformt ("übersetzt") werden, bevor sie ausgeführt werden

können.

Diese Übersetzung ist bei Sprachen wie "C" oder "C++" verhältnismäßig aufwendig. Sie läßt

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, für sich gesehen, nichts

anderes als lesbarer Klartext. Das vom Compiler aus dem Quelltext automatisch produzierte

und dann ausführbare Maschinenprogramm heißt "übersetztes Programm" oder

"Binärprogramm" (engl. binary oder executable). Der Begriff des "Programms" wird sowohl

für Quelltext, wie auch für übersetzte Programme benutzt. Ein Binärprogramm ist nicht

mehr lesbar und i.d.R. wesentlich umfangreicher als der ursprüngliche Quelltext. Soweit der

Compiler fehlerfrei arbeitet, verhält sich das Binärprogramm 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 Binärprogramm

produzieren können. Bei umfangreichen Quelltexten wird die für die Übersetzung

aufzuwendende Zeit spürbar, so daß "Interpreter" entwickelt wurden. Interpreter verlangen

keinen kompletten Quelltext, sondern lesen Quelltext Schritt für Schritt und führen jeden

gelesenen Schritt sofort aus. Damit kann z.B. der Anfang eines Programms schon ausprobiert

werden, bevor das Ende überhaupt fertig ist. Der Preis für diese gewonnene Flexibilität ist

gegenüber einem Binärprogramm reduzierte Ablaufgeschwindigkeit, weil Compiler

Informationen aus dem gesamten Programm für Optimierungen verwenden können.

Darüber hinaus eignen sich nicht alle Programmiersprachen (zu ihnen zählen auch "C" und

"C++") von ihrem Aufbau her für schrittweise Ausführung, weil sich z.B. Programmteile an

weit auseinander liegenden Stellen gegenseitig beeinflußen.

Diese Skizze zeigt schematisch die Entwicklung eines Programmes:

(Schraffierte Kästen sind ausführbare Programme, Kästen ohne Schraffur sind Daten;)

2.6 Programm-Quelltext

Der Quelltext eines C(++)-Programm wird zunächst als Text geschrieben. Dabei sind einige

allgemeine Regeln zu beachten:

2.6.1 Zwischenräume und Leerzeilen

Unter dem Begriff "Zwischenraum" werden üblicherweise Folgen bestimmter

Kontrollzeichen verstanden:

•

•

•

Leerzeichen ("Space" oder "Blank"),

Tabulator ("Tab")

Zeilenwechsel ("Return" oder "Enter")

Zwischenräume werden benutzt, um Quelltext optisch (d.h. für den menschlichen Leser

übersichtlich) zu gliedern. Das Gesamt-Arrangement (Wort-Abstand, Einrückung, Leerzeilen)

wird unter dem Begriff "Layout" zusammengefaßt.

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 persönlichen Programmierstils schlägt sich zu einem guten Teil in

einem einheitlichen Layout nieder. Dabei wird allgemein anerkannt, daß die konkrete Art

des persönlichen Stils eine untergeordnete Rolle spielt, wenn er nur konsequent

durchgehalten wird.

2.6.2 Groß- und Kleinschreibung

Große und kleine Buchstaben werden von C(++) . als unterschiedlich betrachtet.

2.6.3 Umlaute und Sonderzeichen

Auf vielen Tastaturen finden sich nationale Sonderzeichen. Aber längst nicht alle Compiler

können mit Sonderzeichen umgehen. Man sollte sich daher auf die Zeichen beschränken, die

auf US-amerikanischen Tastaturen zu finden sind.

Insbesondere mögen deutsche Umlaute oder etwa das Paragraphenzeichen zwar von einem

Compiler "geschluckt" werden, der nächste Compiler kann aber vollkommen unberechenbar

darauf reagieren.

2.6.4 Kommentare

Ebenfalls der besseren Lesbarkeit dienen Kommentare, d.h. Klartext-Fragmente, die vom

Compiler ignoriert werden.

Kommentare können auf zwei Arten eingefügt werden:

Längere Passagen

werden durch die Zeichenfolge /* eingeleitet und mit */ abgeschlossen. Art und Umfang des

eingebetteten Textes sind beliebig, nur kann die Zeichenfolge */ nicht Inhalt des

Kommentartextes sein. Ein Beispiel:

/* dieser Text

wird vom Compiler ignoriert.

*/

Derartige Kommentare können nicht geschachtelt werden, wie etwa im folgenden

(fehlerhaften) Versuch:

/* Anfang eines Kommentars

/* Fortsetzung */

kein Kommentartext mehr!

*/

Kurze Passagen

werden mit der Zeichenfolge // begonnen und enden automatisch mit der Zeile. (Dies ist

einer der wenigen Fälle, in denen ein bestimmtes Zwischenraumzeichen signifikant ist, d.h.

Einfluß auf die Bedeutung des Programms trägt.) Ein Beispiel:

int a; // Zweck dieser Variablen

Beide Kommentararten dürfen gemischt werden. Die Art des Kommentar-Anfangs regelt die

Art des Endes.

Über Regeln für sinnvolle Inhalt von Kommentaren gibt es lange und fruchtlose Debatten.

Ich persönlich möchte mich den folgenden Vorschlägen anschließen:

Comments are good, but there is also a danger of over-commenting. NEVER try to explain

HOW your code works in a comment: it's much better to write the code so that the working

is obvious, and it's a waste of time to explain badly written code.

Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to

avoid putting comments inside a function body: if the function is so complex that you need

to separately comment parts of it, you should probably go back to chapter 4 for a while. You

can make small comments to note or warn about something particularly clever (or ugly), but

try to avoid excess. Instead, put the comments at the head of the function, telling people

what it does, and possibly WHY it does it.

(Auszug aus: Documentation/CodingStyle, Dokumentation der Linux-Kernelquellen)

FH München, FB 07 Informatik/Mathematik

Prof. Dr. R. Schiedermeier - Vorlesung "Programmieren I"