<iostream> vs.<iostream.h> vs.“iostream.h"

StackOverflow https://stackoverflow.com/questions/214230

  •  03-07-2019
  •  | 
  •  

Frage

Beim einbinden einer header-Datei in C++, was ist der Unterschied zwischen...

1) einschließlich der .h versus nicht einschließlich der .h beim wickeln es in < > Zeichen?

#include <iostream> vs. #include <iostream.h>

2) wickeln Sie den header-Namen in doppelte Anführungszeichen Vergleich wickeln Sie es in < > Zeichen? 

#include <iostream.h> vs. #include "iostream.h"

Vielen Dank im Voraus!

War es hilfreich?

Lösung

Kurz gesagt:

iostream.h ist veraltet - es ist die ursprüngliche Version Stroustrup und Iostream ist die Version aus dem Normenausschuss. Im Allgemeinen Compiler sie beide auf das gleiche Objekt zeigen, aber einige ältere Compiler nicht die älteren haben. In einigen Fällen werden sie ungerade beide existieren und unterschiedlich sein (Legacy-Code unterstützen), und Sie müssen dann spezifisch sein.

„“ versus <> bedeutet einfach die lokalen Verzeichnisse für den Header überprüfen, bevor in die Bibliothek gehen (in den meisten Compiler).

-Adam

Andere Tipps

Hier ist ein anständiger Link Artikel.

Um es zusammenzufassen, ist der Grund gegeben:

  

Die Version der iostream-Bibliothek, die die Standards Committee   hergestellt war schon etwas anders aus der Cfront Umsetzung.   {Schnipp}

     

Übergang zu erleichtern, erklärte der C ++ Standards Committee, dass Code   einschließlich der Standard-C ++ Header verwenden würden Richtlinien enthalten, die   fehlt eine Verlängerung. Dies erlaubt Compiler Anbieter den alten Stil zu versenden   C ++ Bibliothek Header mit der Erweiterung .h und den neuen Stil-Header   ohne.

Ein Vorteil nicht die .h Version mit:

  

Es gibt mehrere Gründe, warum neuer Code geschrieben werden soll mit dem   erweiterungs Version der Header-Dateien anstelle der .h Formen. Das   erste ist die Unberechenbarkeit eines solchen Codes, wenn sie auf modernen zusammengestellt   Compiler. Wie bereits erwähnt, den .h Header das Ergebnis der Verwendung   ist die Umsetzung spezifisch. Und wie die Zeit vergeht, ist die Chance, dass ein   gegeben Compiler werden die alten Stil-Bibliothek zur Verfügung verringert haben.

Da die Person auf dem Normenausschuss (X3J16), der die .h Weglassen vorgeschlagen, meine ursprüngliche Absicht war es, die Debatte über .h, .H, .hpp, .hxx oder .h ++ Dateierweiterungen zu begleichen; oder ein Wunsch von einigen, dass es in der Norm keine Implikation, dass dies der Name einer Datei auf der Festplatte, um einem IDE-vorkompilierte zu ziehen Header-Informationen aus irgendwo zu ermöglichen, war intern wie eine Ressource-Datei oder auch die Gedärme der Compiler.

Während Unix die Dateinamen als eine einzige Zeichenfolge zu sein und eigentlich nicht das Konzept einer Erweiterung erkennen, hatten Dezember Betriebssysteme eine Tradition die Namen von der Erweiterung trennt, und zum Zuführen der „Standarderweiterung“, wenn es weggelassen wurde bestimmte Kontexte. Das ist, wo ich auf die Idee kam von der es bis zur Umsetzung verlassen zu verwenden, was Erweiterung nutzen die Umsetzung wollte, und es erlaubt die Umsetzung nicht einmal auf der Festplatte diese eine Datei zu haben. (Ich war rep Dezember im Ausschuß zu der Zeit.)

Die Unterscheidung zwischen der Norm und den Pre-Standard-Header war ein zusätzlicher Vorteil.

Die Standardmethode (und die einzige Arbeit garantiert) ist . Auf gcc (welche als enthalten könnte sein müssen ), um die entsprechenden Erklärungen zu der globalen Namespace zieht (so brauchen Sie nicht die std :: Namespacepräfix).

„iostream.h“ würde versuchen, zuerst aus dem Verzeichnis mit Ihrem Quellcode, da „“ für Header aus dem Projekt gedacht. <> Sollte immer für System-Header verwendet werden, und „“ für Ihre eigenen Header.

Typisch <> ist für System- oder Standardbibliotheksdateien während „“ verwendet wird für die Projektdateien. Ich wäre nicht überrascht, wenn Ihr Compiler lokal sucht und, wenn es nicht finden kann, wird standardmäßig die Standard-Bibliothek Version es.

Wie für die .h, glaube ich nicht, dass es tatsächlich wichtig ist, wenn Sie C verwenden In C ++, ich erinnere mich vage, dass es eine neuere Version war und eine ältere Version und dass ohne die h angenommen wurde die neue Version sein, aber ich bin nicht einmal sicher, dass die alte Version noch existiert.

Diese sind wirklich zwei verschiedene Fragen.

  • Der Unterschied zwischen der .h und erweiterungs Header mit dem gleichen Name ist historisch. Diejenigen, die mit die Erweiterung .h werden aus dem Original C ++ Standard, der nicht tat haben einige moderne Funktionen wie Namespaces und Vorlagen. Es war einfacher für den neuen Standard zu setzen dass gleiche Funktionalität in neuen Header-Dateien in der Lage sein diese zu verwenden neue Funktionen und halten Sie die alte (.h) Dateien für die Abwärtskompatibilität von Legacy-Code.

  • Der Unterschied zwischen der # include <...> und # include "..." Format Die Reihenfolge, in der der Compiler sucht nach Dateien. Dies ist im Allgemeinen Umsetzung abhängig, aber die Idee ist, dass das <> Format sieht in System umfassen Verzeichnisse zuerst, während „“ sieht im gleichen Verzeichnis als Quelldatei #include, dass es zuerst.

Die einfache Antwort auf die erste Antwort ist, dass iostream.h nicht, zumindest in der GCC-Implementierung vorhanden ist. Wenn Sie auf * nix, geben Sie

% lokalisieren iostream.h
/ usr / include / c ++ / 3.4.3 / rückwärts / iostream.h

und

% lokalisieren Iostream
/usr/include/c++/3.4.3/iostream
/ usr / include / c ++ / 3.4.3 / rückwärts / iostream.h

Wie Zee Artikel sagt, iostream.h ist für die Abwärtskompatibilität.

In Bezug auf die Namen der standard-C++ - header-Dateien, in den frühen Tagen (erste 2 Jahre) X3J16, mit dem wir konfrontiert waren, ein argument, über das, was die Erweiterung sollte auf den standard C++ - header-Dateien.Im Einsatz, die damals von verschiedenen Herstellern (und geprägt durch Zwänge, dass einige Betriebssysteme auf Datei-Namen) ich glaube es waren .h, .H, .h++, .hpp, .HXX, und eventuell andere.In einer Bibliothek Gruppe treffen, schlug ich vor, wir lassen Sie die Erweiterung aus, und lassen Sie es bis zur Umsetzung und liefern Standard-Datei-Erweiterung, der seine Wahl wenn es war keiner in der include-Zeile, oder verwenden Sie den Namen, die als Schlüssel in einer Datenbank der vorkompilierten header-Dateien, falls gewünscht.[Und Unix-ähnlichen Systemen behandeln, die mit dem Namen und "Erweiterung" bezeichnet, als eine einzelne Zeichenfolge, war ich Vertreter DEC auf das Komitee und vielen DEC-Betriebssystemen gespeichert werden, ist die Erweiterung in das Verzeichnis als separates Feld von den Namen.So DEC-Betriebssystemen hat eine starke tradition in der Anwendung eine Standard-Erweiterung basierend auf dem, was das Programm war auf die Datei zugreift, für welchen Zweck.Zu sagen, ein assembler 'X,Y=Z' führen könnten, das Lesen der Eingabedatei Z. MAC (makro) und die Ausgabe-Dateien X. OBJ und Y. LST.] Trotzdem, es vermieden, eine lange, no-win-Debatte, so ging die Gruppe zusammen mit ihm und Andy Koenig präsentiert die Gruppe die Schlussfolgerungen zu diesen (unter anderem) auf das gesamte Komitee, die es akzeptiert.Ich finde es etwas amüsant, dass Implementierungen verpasste der ganze Punkt, dass Sie könnte gelten eine Standard-Erweiterung von Ihre Wahl (ich würde denken, wäre nützlich, um Editoren und andere Hilfsmittel) und Links nur die Erweiterung aus der Datei name.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top