& Lt; iostream > vs. < iostream.h > vs. "iostream.h"

Question

Quando si include un file di intestazione in C ++, qual è la differenza tra ...

1) incluso il .h rispetto al non includere il .h quando lo avvolgi in < & Gt; segni?

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

2) racchiudendo il nome dell'intestazione tra virgolette doppie anziché racchiudendolo in < & Gt; segni?

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

Grazie in anticipo!

Answer 1

In breve:

iostream.h è obsoleto: è la versione originale di Stroustrup e iostream è la versione del comitato standard. Generalmente i compilatori li indicano entrambi sulla stessa cosa, ma alcuni compilatori più vecchi non avranno quello più vecchio. In alcuni casi strani entrambi esisteranno e saranno diversi (per supportare il codice legacy) e quindi dovrai essere specifico.

" " contro < > significa semplicemente controllare le directory locali per l'intestazione prima di andare in libreria (nella maggior parte dei compilatori).

-Adam

Answer 2

Ecco un link decente articolo.

Per riassumere, il motivo indicato:

  

La versione della libreria iostream che lo Standards Committee   prodotto era piuttosto diverso dall'implementazione di CFront.   {Snip}

     

Per facilitare la transizione, il C ++ Standards Committee ha dichiarato quel codice   tra cui le intestazioni standard C ++ userebbero includere direttive che   manca un'estensione. Ciò ha consentito ai produttori di compilatori di inviare il vecchio stile   Intestazioni di libreria C ++ con estensione .h e nuove intestazioni di stile   a meno.

Un vantaggio di non usare la versione .h:

  

Esistono diversi motivi per cui il nuovo codice deve essere scritto usando il   versione senza estensione dei file di intestazione anziché i moduli .h. Il   il primo è l'imprevedibilità di tale codice quando compilato in chiave moderna   compilatori. Come accennato in precedenza, il risultato dell'utilizzo delle intestazioni .h   è specifica dell'implementazione. E col passare del tempo, la possibilità che a   dato compilatore avrà riduzioni disponibili della vecchia libreria di stile.

Answer 3

In quanto persona del comitato degli standard (X3J16) che ha proposto di abbandonare il .h, il mio intento originale era di risolvere il dibattito sulle estensioni di file .h, .H, .hpp, .hxx o .h ++; o il desiderio da parte di alcuni di non avere implicazioni nello standard secondo cui questo era il nome di un file su disco al fine di consentire a un IDE di estrarre informazioni di intestazione precompilate da un punto interno come un file di risorse o persino il coraggio del compilatore.

Mentre Unix considerava il nome del file come una singola stringa e in realtà non riconosceva il concetto di estensione, i sistemi operativi DEC avevano la tradizione di separare il nome dall'estensione e fornire l'estensione "predefinita". se è stato omesso in contesti particolari. È lì che mi è venuta l'idea di lasciarlo all'implementazione per usare qualunque estensione l'implementazione volesse usare, e ha permesso all'implementazione di non avere nemmeno questo un file sul disco. (All'epoca ero il rappresentante di DEC in commissione.)

La differenza tra le intestazioni standard e pre-standard è stata un ulteriore vantaggio.

Answer 4

Il modo standard (e l'unico garantito per funzionare) è & iteam > ;. Su gcc, < iostream.h > (che potrebbe essere necessario includere come < backward / iostream.h >) estrae le dichiarazioni pertinenti nello spazio dei nomi globale (quindi non è necessario il prefisso std :: namespace).

" iostream.h " proverei prima dalla directory con il tuo codice sorgente, poiché " " è pensato per le intestazioni del tuo progetto. & Lt; > deve essere sempre utilizzato per le intestazioni di sistema e " " per le tue intestazioni.

Answer 5

In genere < > viene utilizzato per file di libreria di sistema o standard mentre "quot". viene utilizzato per i file di progetto. Non sarei sorpreso se il tuo compilatore cerca localmente e quando non lo trova, passa alla versione standard della libreria.

Per quanto riguarda il .h, non penso che importi davvero se usi C. In C ++, ricordo vagamente che esisteva una versione più recente e una versione precedente e che senza la h avrebbe dovuto essere la nuova versione, ma non sono nemmeno sicuro che la vecchia versione esista ancora.

Answer 6

Queste sono davvero due domande diverse.

• La differenza tra .h e intestazioni senza estensione con lo stesso il nome è storico. Quelli con l'estensione .h proviene da standard C ++ originale che non lo ha fatto hanno alcune caratteristiche moderne come spazi dei nomi e modelli. Era più semplice da inserire per il nuovo standard la stessa funzionalità nel nuovo file di intestazione per poterli usare nuove funzionalità e mantenere il vecchio (.h) file per la retrocompatibilità di codice legacy.

• La differenza tra #include & Lt; ... > e #include " ... " il formato è l'ordine in cui il compilatore cerca i file. Questo è generalmente implementazione dipendente, ma il l'idea è che il < > il formato appare il sistema include prima le directory, mentre " " guarda nella stessa directory come file sorgente che lo includeva # prima.

Answer 7

La semplice risposta alla prima risposta è che iostream.h non esiste, almeno nell'implementazione di GCC. Se sei su * nix, digita

% individuare iostream.h
/ usr / include / C ++ / 3.4.3 / indietro / iostream.h

e

% individuare iostream
/usr/include/c++/3.4.3/iostream
/ usr / include / C ++ / 3.4.3 / indietro / iostream.h

Come dice l'articolo di Zee, iostream.h è per la retrocompatibilità.

Answer 8

Per quanto riguarda i nomi dei file di intestazione C ++ standard, nei primi giorni (primi 2 anni) di X3J16, abbiamo affrontato un argomento su quale estensione dovrebbe essere sui file di intestazione C ++ standard. In uso all'epoca da vari fornitori (e influenzato dai vincoli che alcuni sistemi operativi ponevano sui nomi dei file) credo che esistessero .h, .H, .h ++, .hpp, .HXX e forse altri. In una riunione di un gruppo di biblioteche ho suggerito di lasciare l'estensione disattivata e lasciarla all'implementazione per fornire un'estensione di file predefinita di sua scelta se non ce n'era nella riga include o utilizzare il nome come chiave in un database file di intestazione precompilati, se desiderato. [Mentre i sistemi simili a Unix trattano il nome del file e "estensione" come una singola stringa, stavo rappresentando DEC nel comitato e molti sistemi operativi DEC memorizzavano l'estensione nella directory come un campo separato dal nome. Quindi i sistemi operativi DEC avevano una forte tradizione di applicazione di un'estensione predefinita basata su quale programma stava accedendo al file per quale scopo. Dire ad un assemblatore 'X, Y = Z' potrebbe comportare la lettura del file di input Z.MAC (macro) e la scrittura dei file di output X.OBJ e Y.LST.] Comunque, ha evitato un lungo dibattito senza vincita, quindi il gruppo lo ha seguito, e Andy Koenig ha presentato le conclusioni del gruppo su questo (tra gli altri) all'intero comitato che lo ha accettato. Trovo in qualche modo divertente il fatto che le implementazioni abbiano perso il punto di poter applicare un'estensione predefinita di loro scelta (che riterrei utile per gli editor e altri strumenti) e che abbia lasciato l'estensione al di fuori del nome del file.