Wenn Sie eine Header-Datei in C++ einbinden, was ist der Unterschied zwischen...
1) die Einbindung von .h gegenüber der Nicht-Einbindung von .h bei der Einbettung in < > Zeichen?
#include <iostream> vs. #include <iostream.h>2) den Namen der Kopfzeile in doppelte Anführungszeichen zu setzen und nicht in < >-Zeichen zu setzen?
#include <iostream.h> vs. #include "iostream.h"Vielen Dank im Voraus!
Die einfache Antwort auf die erste Frage ist, dass iostream.h nicht existiert, zumindest nicht in der GCC-Implementierung. Wenn Sie unter *nix arbeiten, geben Sie
% iostream.h lokalisieren
/usr/include/c++/3.4.3/backward/iostream.h
et
% locate iostream
/usr/include/c++/3.4.3/iostream
/usr/include/c++/3.4.3/backward/iostream.h
Wie Zee's Artikel sagt, ist iostream.h für die Abwärtskompatibilität.
Das sind eigentlich zwei verschiedene Fragen.
Der Unterschied zwischen den .h- und Headern ohne Erweiterung mit demselben Namen ist historisch bedingt. Die Header mit der Erweiterung .h stammen aus dem ursprünglichen C++-Standard, der noch nicht einige moderne Funktionen wie Namespaces und Namespaces und Vorlagen. Es war war es für den neuen Standard einfacher, die die gleiche Funktionalität in neue Header-Dateien zu packen, um diese neuen neuen Funktionen zu nutzen und die alten (.h) Dateien für die Abwärtskompatibilität von Legacy-Code.
Der Unterschied zwischen dem #include <...> und dem #include "..." Format ist die Reihenfolge, in der der Compiler nach Dateien sucht. Dies ist im Allgemeinen Implementierung abhängig, aber die Idee ist, dass das <> Format zuerst in System-Include-Verzeichnisse zuerst sucht, während "" in demselben Verzeichnis sucht wie die Quelldatei, die es #includiert zuerst.
Was die Namen der Standard-C++-Header-Dateien angeht, so gab es in den ersten Tagen (in den ersten zwei Jahren) von X3J16 einen Streit darüber, wie die Erweiterung der Standard-C++-Header-Dateien lauten sollte. Ich glaube, es gab .h, .H, .h++, .hpp, .HXX und möglicherweise noch andere, die damals von verschiedenen Anbietern verwendet wurden (und von den Einschränkungen beeinflusst waren, die einige Betriebssysteme für Dateinamen vorgaben). In einer Bibliotheksgruppensitzung schlug ich vor, die Erweiterung wegzulassen und es der Implementierung zu überlassen, eine Standard-Dateierweiterung ihrer Wahl anzugeben, wenn in der Include-Zeile keine vorhanden war, oder den Namen als Schlüssel in einer Datenbank mit vorkompilierten Header-Dateien zu verwenden, falls gewünscht. [Während Unix-ähnliche Systeme den Dateinamen und die "Erweiterung" als eine einzige Zeichenkette behandeln, vertrat ich DEC in dem Ausschuss, und viele DEC-Betriebssysteme speicherten die Erweiterung im Verzeichnis als ein vom Namen getrenntes Feld. DEC-Betriebssysteme hatten also eine starke Tradition, eine Standard-Erweiterung anzuwenden, je nachdem, welches Programm zu welchem Zweck auf die Datei zugriff. Die Anweisung an einen Assembler 'X,Y=Z' konnte dazu führen, dass die Eingabedatei Z.MAC (Makro) gelesen und die Ausgabedateien X.OBJ und Y.LST geschrieben wurden]. Wie auch immer, es vermied eine lange, aussichtslose Debatte, so dass die Gruppe dem zustimmte und Andy Koenig die Schlussfolgerungen der Gruppe (neben anderen) dem gesamten Ausschuss vorstellte, der sie akzeptierte. Ich finde es etwas amüsant, dass die Implementierungen den ganzen Punkt übersehen haben, dass sie eine Standarderweiterung ihrer Wahl anwenden können (was meiner Meinung nach für Editoren und andere Werkzeuge nützlich wäre) und die Erweiterung einfach aus dem Dateinamen weggelassen haben.
seufzend Entschuldigung, ich sehe jetzt, dass ich bereits über dieses Thema geschrieben habe. So etwas passiert, wenn ich die falsche Brille aufhabe :-) Nun, ich hoffe, dass diese Version ein oder zwei weitere Informationen zu den historischen Aufzeichnungen beiträgt.
Sie können sie in einer Antwort zusammenfassen, indem Sie Bearbeitung die höchste Punktzahl und löschen Sie diese. (Aber *************** ohne ************ "Bearbeiten:", "Aktualisieren:" o.ä. - die Antwort sollte so erscheinen, als wäre sie geschrieben worden heute . Dafür ist der Revisionsverlauf / die Bearbeitungszusammenfassung gedacht. Die historischen Informationen stehen in der Revisionsgeschichte und gehören nicht in die aktuelle Version. Es tut mir leid, wenn es offensichtlich erscheint, aber die meisten Leute verstehen es nicht richtig).
Es steht dem Compiler frei, ein fehlendes ".h" hinzuzufügen (oder was auch immer) an einen Standard-Header-Namen anhängen, um den Namen der tatsächlich zu lesenden Datei auf der Festplatte zu ermitteln, wenn der Compiler tatsächlich Standard-Header von tatsächlichen Dateien auf der Festplatte erhält. Das Benutzerprogramm kann also sagen: "#include <iostream>", und der Compiler könnte klug genug sein, eine Datei mit dem Namen "iostream.h" zu öffnen (oder was immer er will) in einem Verzeichnis zu öffnen, das ihm bekannt ist (oder das ihm über Befehlszeilenschalter mitgeteilt wird). Der Standard schreibt nicht vor, dass der Standard-Header in einer tatsächlichen Textdatei mit einem bestimmten Namen auf der Festplatte stehen muss.
Ja, ich finde es traurig, dass die Compiler-Autoren nicht die Möglichkeit genutzt haben, den Namen von Header-Dateien mit einer Erweiterung zu versehen, so dass Benutzer, Editoren und andere Tools die Sprache, in der eine Datei vorliegt, anhand des Namens bestimmen können, während die Portabilität durch die Einhaltung von Standards in der #include-Direktive erhalten bleibt. ... Wenn Sie meinten, dass der Header nicht aus einer Textdatei kommt, kann der Compiler auf VMS eine .TLB (Textbibliothek [Archiv])-Datei öffnen und den Header daraus abrufen: forum.vmssoftware.com/viewtopic.php?t=39
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
