Vorlesungsskript - Hochschule Emden/Leer

Weitere Magazine

Empfehlungen

Info

c○ Prof. Dr. B. Bartning, HS Emden/Leer Rumpfskript ” Informatik I/II“ (WS/SS 2010/11) 94 void fehlerSchieben(); // Fehlermeldung Schieben void fehlerHolen(); // Fehlermeldung Holen int kellerSpeicher(bool schiebenJaNein,int wert) { static const int maxanz=100; // "static": statische SpKl static int speich[maxanz], // "static": statische SpKl zaehler=0; } if (schiebenJaNein) { if (zaehler==maxanz) fehlerSchieben(); // Fehler else speich[zaehler++]=wert; } else { if (zaehler) wert=speich[--zaehler]; else { fehlerHolen(); // Fehler wert=0; // damit definierter Wert } } return wert; void fehlerSchieben() { cout
c○ Prof. Dr. B. Bartning, HS Emden/Leer Rumpfskript ” Informatik I/II“ (WS/SS 2010/11) 95 (8.21) es eigentlich sein sollte; das Verbergen wird durch zusätzliche Kennzeichung erreicht. Ohne diese zusätzliche Kennzeichnung hat ein Name externe Bindung und ist daher öffentlich. In C++(neu) gilt es jedoch als missbilligt, Namen durch interne Bindung zu verbergen. Die neue und zu bevorzugende Vorgehensweise geschieht mit unbenannten Namensbereichen (8.23a). Das allgemeine Konzept der Namensbereiche wird in (8.23c) kurz erläutert. Um bei den Namen, die öffentlich sein sollen, nicht in sehr schwer handhabbare Konsistenzprobleme zu geraten, hat sich schon in C ein recht interessantes Konzept entwickelt, das auch in C ++ ausgiebig angewandt wird: die Abspaltung der Deklarationen von Namen mit externer Bindung in sog. Headerdateien. Diese Headerdateien werden dann mit Hilfe einer Include-Direktive in jede Programmdatei eingefügt, in der die dort erwähnten Namen in irgendeiner Weise auftreten, d. h. benutzt oder auch definiert werden. Eine genaue Auflistung, welche Bestandteile zu einer Header- und welche zu einer Programmdatei gehören, ist in (8.24) ausführlich beschrieben. Anm Eine Ausnahme bilden die Typdefinitionen, meist in Form von Klassendefinitionen (Kap. 9); hier erscheinen i. a. sogar die Definitionen in Headerdateien. Zwei ausführliche C ++-Beispielprogramme (8.25, 8.26) erläutern den Umgang mit mehreren Programmdateien. Die Besonderheiten beim Zusammenbinden von C- und C ++-Programmdateien sind in (8.27) zusammengestellt. (a) Um ein Zusammenspiel zwischen verschiedenen Übersetzungseinheiten zu erlauben, müssen dem Linker in den Objektdateien (d. h. kompilierten Dateien) zu verknüpfende Namen angegeben werden. Die Stellen, an denen Referenzen benötigt werden (z. B. ein Funktionsaufruf), werden durch den Linker verknüpft ( ” aufgelöst“) mit Referenzangeboten (z. B. eine Funktionsdefinition). Diese Namen, die der Linker in den Objektdateien erhält, unterliegen der sog. externen Bindung 〈external linkage〉. Zu den Begriffen Objektdatei oder Objektprogramm, Linker oder Binder s. (1.32). Dagegen haben Namen einer Übersetzungseinheit, die für den Linker versteckt sind, die sog. interne Bindung 〈internal linkage〉. Daher können Namen mit interner Bindung nie mit gleichlautenden Namen anderer Übersetzungseinheit kollidieren. Eine bessere Möglichkeit, Namen zu verbergen, wird in C++(neu) durch einen unbenannten Namensbereich 〈unnamed namespace〉 angeboten. Dieses wird im Folgenden normalerweise eingesetzt. (b) Beim Zusammenspiel mehrerer Übersetzungseinheiten sollte daher folgende Regel beachtet werden: • Namen sollten normalerweise verborgen sein (durch interne Bindung oder besser durch Einschluss in einen unbenannten Namensbereich), und zwar wegen der Übersichtlichkeit; dann gibt auch keine Namenskonflikte mit anderen Übersetzungseinheiten. • Nur wenn eine Kommunikation mit anderen Übersetzungseinheiten nötig ist, sollte die externe Bindung vergeben werden. Dieses sollte bei jedem Namen geprüft werden! Diese Regel unterstützt auch das Geheimnisprinzip (6.13c). (c) Beispiele: Namen von Funktionen, die in anderen Übersetzungseinheiten aufgerufen werden sollen, müssen externe Bindung erhalten. Dagegen sollten Funktionen, die für andere Funktionen der gleichen Übersetzungseinheit Serviceberechnungen durchführen, verborgen werden. Variable sollten (fast) immer verborgen sein! (d) In diesem Zusammenhang ist die Regel genau einer Definition 〈one definition rule (ODR)〉 wichtig: Zu externen Namen darf und muss genau eine Definition (Referenzangebot) gehören, alle anderen Übersetzungseinheiten dürfen nur Deklarationen dieses Namens haben. Die ODR gilt natürlich auch für interne Namen. ↑↑ Erlaubt nach den Regeln von C ++/C ist es, dass ein Linker ggf. keine Groß-/Kleinschreibung unterscheidet oder auch nur eine gewisse Anzahl von Zeichen für einen Namen als unterscheidend erkennt. Diese Beschränkung trifft heutzutage selten zu. Bei deklarierten Funktionen kann auf eine Definition verzichtet werden, wenn sie nirgendwo aufgerufen werden (7.23 Anm3).
Seite 1 und 2:
Informatik I/II Studiengänge Photo
Seite 3 und 4:
c○ Prof. Dr. B. Bartning, HS Emde
Seite 5 und 6:
Seite 7 und 8:
Seite 9 und 10:
Seite 11 und 12:
Seite 13 und 14:
Seite 15 und 16:
Seite 17 und 18:
Seite 19 und 20:
Seite 21 und 22:
Seite 23 und 24:
Seite 25 und 26:
Seite 27 und 28:
Seite 29 und 30:
Seite 31 und 32:
Seite 33 und 34:
Seite 35 und 36:
Seite 37 und 38:
Seite 39 und 40:
Seite 41 und 42:
Seite 43 und 44: c○ Prof. Dr. B. Bartning, HS Emde
Seite 93: c○ Prof. Dr. B. Bartning, HS Emde
Seite 145 und 146:
Seite 147 und 148:
Seite 149 und 150:
Seite 151 und 152:
Seite 153 und 154:
Seite 155 und 156:
Seite 157 und 158:
Seite 159 und 160:
Seite 161 und 162:
Alle anzeigen

Vorlesungsskript - Hochschule Emden/Leer

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?