Frage zu Headerfiles
-
Der Standard spricht eigentlich nicht von Compilern und Libraries, sondern nur allgemein von der Implementierung. Ich bin mir ziemlich sicher, dass er nirgeds garantiert oder auch nur andeutet, dass man die Standardbibliothek austauschen können muss. Das geht schon allein deshalb nicht, weil die Standardbibliothek nicht vollständig in Standard-C++ implementiert werden kann. Es müsste also eine Kern-API geben, auf die dann eine in Standard-C++ geschriebene, austauschbare Standardbibliothek aufsetzen kann. Aber die gibt es nicht.
-
Der Standard garantiert, dass die Standardbibliothek (also die Deklarationen) als "Header" vorliegt. Eine Fußnote weist aber ausdrücklich darauf hin, dass mit "Header" etwas gemeint ist, was mit #include<...> eingebunden werden kann, aber nicht zwangsläufig eine Datei sein muss. Im Gegensatz zu #include"...", welches nur Dateien einbindet. Falls dieser Fall vorliegt und man seine eigene Datei mit dem Namen des Headers bereitstellt, ist das Verhalten undefiniert.
Alles Kapitel 17.
Ich muss zugeben: Hat mich jetzt etwas überrascht.
-
Artchi schrieb:
Namespaces sind offen
Mit Ausnahme des
namespace std(§17.4.3.1)SeppJ schrieb:
Der Standard garantiert, dass die Standardbibliothek (also die Deklarationen) als "Header" vorliegt. Eine Fußnote weist aber ausdrücklich darauf hin, dass mit "Header" etwas gemeint ist, was mit #include<...> eingebunden werden kann, aber nicht zwangsläufig eine Datei sein muss. Im Gegensatz zu #include"...", welches nur Dateien einbindet. Falls dieser Fall vorliegt und man seine eigene Datei mit dem Namen des Headers bereitstellt, ist das Verhalten undefiniert.
Alles Kapitel 17.
Ich muss zugeben: Hat mich jetzt etwas überrascht.
Okay, mich auch. Ich muss gestehen dass bei mir auch der Gedächtnis-ohne-Referenzen-Fall vorlag bzgl. Austauschbarkeit der Bibliotheken.
vgl. auch §16.2,2 bzgl. Header-inclusion vs. Sourcefile-inclusionWobei ich aber bleibe:
Die Implementierung der Standardbibliothek hat nicht zwangsläufig mit dem Compiler zu tun. Lediglich die Orte, wo die Definitionen und Deklarationen zu finden sind, sind Compilerabhängig. Das folgt auch aus Kap. 17 sowie 16.2,2: Die Header-includes sorgen nach 16.2,2 dafür, dass an der Stelle der inlcude-Direktive der Inhalt des Headers in die Übersetzungseinheit eingefügt wird. Und wie auch immer der Header aussieht und wo er liegt, muss sein Inhalt dementsprechend standardkonformes C++ sein (Modulo Extensions wie im MSVC-Fall).Bashar schrieb:
Der Standard spricht eigentlich nicht von Compilern und Libraries, sondern nur allgemein von der Implementierung.
Der Standard spricht sehr wohl an einigen Stellen von der Library (manchmal auch der standard library) und der library implementation. Allerdings wird mehr oder weniger implizit davon ausgegangen, dass diese library (und damit auch ihre implementation) Teil der "implementation" ist.
Bashar schrieb:
Das geht schon allein deshalb nicht, weil die Standardbibliothek nicht vollständig in Standard-C++ implementiert werden kann. Es müsste also eine Kern-API geben, auf die dann eine in Standard-C++ geschriebene, austauschbare Standardbibliothek aufsetzen kann. Aber die gibt es nicht.
Die Header-Inhalte müssen wie gesagt in C++ vorliegen. Sie dürfen andere Header einbinden und auf Funktionen zugreifen, die nicht in der library sind.
Da jedoch alles in der library externe linkage hat, können die eigentlichen Funktionen in anderen Sprachen implementiert werden.Einem Compiler, der einen Austausch der Standardbibliotheksimplementierung erlaubt, müsste daher folgende mitgeteilt werden können:
- Ort und Aufbau der Library Header
- Wie die in der Bibliothek definierten Objekte und Funktionen vor Programmstart (
) in das Programm eingebunden werden. Nach 17.4.2.2,3 müssen die Inhalte der Standardbibliothek nicht zur Linkzeit mit ins Programm gelinkt werden.
-
pumuckl schrieb:
[...] Und wie auch immer der Header aussieht und wo er liegt, muss sein Inhalt dementsprechend standardkonformes C++ sein (Modulo Extensions wie im MSVC-Fall).
Komische Schlussfolgerung ... sieht ein bischen nach einer Tautologie à la "Der Teil, der standardkonform ist, ist standardkonform" aus.
-
krümelkacker schrieb:
pumuckl schrieb:
[...]
Komische Schlussfolgerung ... sieht ein bischen nach einer Tautologie à la "Der Teil, der standardkonform ist, ist standardkonform" aus.
Sollte bloß verdeutlichen, dass auch wenn ein Header keine eigene Sourcefile sein muss, der Inhalt dennoch C++-Code ist und an der entsprechenden Stelle eingefügt wird und nicht ein #include <iostream> durch irgendwelche Compilermagie dazu führt, dass der plötzlich einfach "weiß" was cin, cout & Co sind.
-
pumuckl schrieb:
[...] der Inhalt dennoch C++-Code ist und an der entsprechenden Stelle eingefügt wird und nicht ein #include <iostream> durch irgendwelche Compilermagie dazu führt, dass der plötzlich einfach "weiß" was cin, cout & Co sind.
Das kannst Du gar nicht verbieten, da es nach der as-if-Regel eigentlich erlaubt sein sollte.
-
krümelkacker schrieb:
pumuckl schrieb:
[...] der Inhalt dennoch C++-Code ist und an der entsprechenden Stelle eingefügt wird und nicht ein #include <iostream> durch irgendwelche Compilermagie dazu führt, dass der plötzlich einfach "weiß" was cin, cout & Co sind.
Das kannst Du gar nicht verbieten, da es nach der as-if-Regel eigentlich erlaubt sein sollte.
In den betreffenden Sätzen gibts keine as-if-Regeln:
§16.2,2 schrieb:
A preprocessing directive of the form
# include<h-char-sequence> new-line
[...], and causes the replacement of that directive by the entire contents of the header.[...]§17.4.2.1,1 schrieb:
The entities in the C++ Standard Library are defined in headers, whose contents are made available to a translation unit when it contains the appropiate
#includepreprocessing directive (16.2)
-
17.4.1.2§1:
The elements of the C++ Standard Library are declared or defined (as appropriate) in a header.158)
Mit der Fußnote 158):
A header is not necessarily a source file, nor are the sequences delimited by < and > in header names necessarily valid source file names.
-
Letztlich hängt es an der Interpretation von "are made available to a translation unit". Ich würde nicht sagen, dass dies zwangsläufig das Einfügen von Text bedeuten muss.
-
pumuckl schrieb:
krümelkacker schrieb:
pumuckl schrieb:
[...]
Komische Schlussfolgerung ... sieht ein bischen nach einer Tautologie à la "Der Teil, der standardkonform ist, ist standardkonform" aus.
Sollte bloß verdeutlichen, dass auch wenn ein Header keine eigene Sourcefile sein muss, der Inhalt dennoch C++-Code ist und an der entsprechenden Stelle eingefügt wird und nicht ein #include <iostream> durch irgendwelche Compilermagie dazu führt, dass der plötzlich einfach "weiß" was cin, cout & Co sind.
Naja, ... der Teil mit den "Extensions" führt den Rest etwas ad absurdum
Wenn ich nen Compiler schreibe, dann kann ich z.B. einfach ein File namens "iostream" mit folgendem Inhalt ausliefern
#pragma standard_header("iostream")Der Include-Mechanismus ist dann völlig standardkonform implementiert, cin/cout etc. werden aber trotzdem über "Compilermagie" definiert.
-
SeppJ schrieb:
Letztlich hängt es an der Interpretation von "are made available to a translation unit". Ich würde nicht sagen, dass dies zwangsläufig das Einfügen von Text bedeuten muss.
Der Teil den du zitierst nicht. 16.2,2 "causes the replacement of that directive by the entire contents of the header" besagt aber genau das.
@Bashar: wie oben beschrieben
pumuckl schrieb:
dass auch wenn ein Header keine eigene Sourcefile sein muss,
, das steht in besagter Fußnote.
pumuckl schrieb:
der Inhalt dennoch C++-Code ist und an der entsprechenden Stelle eingefügt wird
Steht in 16.2,2
Die Fußnote besagt nur, dass es keine source-file sein muss. Sie besagt nicht, dass ein header keinen Sourcecode enthalten braucht. IMO bedeutet die Fußnote nur, dass z.B. ein header ein Feld in einer Datenbank sein kann oder ein Abschnitt einer wie auch immer kodierten Datei (aber eben keine eigene Datei mit Namen iostream). Der Inhalt (content) eines Headers muss aber compilierbarer Code sein, da dieser laut 16.2,2 in Phase 4 an Stelle der include-Direktive in den Sourcecode der ÜE eingesetzt wird.
