Vorlesungsskript - Hochschule Emden/Leer

c○ Prof. Dr. B. Bartning, HS Emden/Leer Rumpfskript ” Informatik I/II“ (WS/SS 2010/11) 97
Das Beispiel (8.26) zeigt diese Verwendung von static.
Das Schlüsselwort static ist sehr schillernd, es hat (leider) verschiedene Bedeutungen. Es
kann statische Speicherklasse bedeuten (8.12) oder auch interne Bindung. Um diese Doppelbedeutung
nicht mehr zu unterstützen, sollte static nur noch in der Bedeutung statische
Speicherklasse und nicht mehr in der Bedeutung interne Bindung benutzt werden. Das
letztere gilt daher in C++(neu) als missbilligt (Str3/Kap. B.2.3). An dessen Stelle sollte man daher
einen unbenannten Namensbereich (a) nehmen.
(c) ↑↑ Namensbereiche C++(neu)
Ein Namensbereich dient der logischen Gruppierung von Namen. Zur Vermeidung von Namenskonflikten
und damit der ” globale“ Namensbereich (alle Namen mit externer Bindung über alle
Programmdateien hinweg) nicht überfrachtet wird, kann man eine Gruppe von Namen in einem
Namensbereich ablegen.
40 NamensbereichDefinition namespace NamensbereichNameopt { 10 Deklaration0..n }
Auf Namen eines Namensbereiches kann innerhalb des Bereichs direkt zugegriffen werden, außerhalb
durch explizite Spezifizierung mit dem Operator :: Op1b
NamensbereichName :: Bezeichner
Statt der expliziten Spezifizierung können durch eine using-Direktive sämtliche Namen eines Namensbereiches
zugreifbar gemacht werden, und zwar für den Geltungsbereich, in dem die Direktive
steht. (Bei Namenskonflikten hat der Name des Geltungsbereichs Vorrang vor dem aus dem Namensbereich;
hier hilft dann nur die explizite Spezifizierung.)
UsingDirektive using namespace NamensbereichName ;
Alle Namen der Standardbibliotheken sind neuerdings im Namensbereich std abgelegt, daher die
Direktive ” using namespace std;“. Beim Compiler MS Visual C ++ 6.0 sind in den Headerdateien
ohne .h diese Namen in std abgelegt, bei denen mit .h im globalen Namensraum.
Wenn man NamensbereichName in der Namensbereichdefinition weglässt ( ” unbenannter Namensbereich“,
s. (a)), setzt der Compiler einen eigenen eindeutigen Namensbereich-Namen ein, dazu
eine UsingDirektive für diesen Namen des Namensbereichs. Da für den Programmierer dieser Name
nicht bekannt ist, kann außerhalb der Programmeinheit auf darin deklarierte Namen nicht zugegriffen
werden. Diese Eigenschaft wird entspr. (a) zum Verbergen von Namen benutzt.
(8.24) Headerdateien
(a) Es ist sehr sinnvoll, die Deklarationen für Namen mit externer Bindung von den zugehörigen
Definitionen zu trennen: Headerdatei 〈header file〉 und Programmdatei 〈program file〉. Erstere
hat meist die Dateinamenerweiterung .H oder .h, letztere meist die Erweiterung .CPP
oder .cpp, auch .CXX oder .cxx.
Der wichtigste Grund dafür ist die Konsistenz zwischen Deklaration und Definition: Da
in der Praxis die Programme ” leben“, d. h. immer wieder verändert werden, kann bei einer
Änderung des Namens oder der Signatur einer Funktion vergessen werden, die (ggf. an vielen
Stellen vorhandenen) Deklarationen der neuen Definition anzupassen. Der Linker bemerkt
solche Änderungen nicht immer, so dass sich sehr schwer handhabbare Fehler einschleichen
können. Viel besser ist es daher – zudem auch verbunden mit wesentlich weniger Aufwand
–, genau eine Deklaration in genau eine Headerdatei zu schreiben und diese Datei überall
einzuschließen, wo die Deklaration benötigt wird. Sehr wichtig ist es dann, dass diese Headerdatei
auch in die Programmdatei eingeschlossen wird, die die Definition enthält, damit
der Compiler die Konsistenzprüfung durchführen kann!
(b) Empfehlung:
• Bei nur wenigen Programmdateien (Praxis: bis zu etwa fünf Dateien) genügt es meist,
die Deklarationen aller Programmdateien in eine einzige Headerdatei zusammenzufassen
und diese überall einzuschließen.
• Sonst ist es üblich, je Programmdatei eine Headerdatei (gleicher Dateinamen, Erweiterung
.H oder .h) zu erstellen; diese wird dann, wo nötig, eingeschlossen.
• Manche Bestandteile einer Headerdatei (z. B. Klassendefinitionen (9.11)) dürfen nicht
mehrfach in derselben Übersetzungseinheit eingeschlossen sein. Wenn jedoch eine Headerdatei
eine andere einschließt (z. B. wegen benötigter Typendefinition), kann es leicht
zu einem (indirekten) Doppeleinschluss kommen. Durch die Möglichkeiten der bedingten
Kompilierung kann man jedoch leicht einen Include-Wächter einfügen; Näheres s.
(5.75c) und die Beispiele (8.25a) und (9.31a).