< iostream > vs. < iostream.h > vs. & # 8220; iostream.h & # 8221;

Question

Al incluir un archivo de encabezado en C ++, ¿cuál es la diferencia entre ...

1) incluyendo la .h versus no incluir la .h cuando lo envuelve en < > señales?

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

2) envolviendo el nombre del encabezado entre comillas dobles en lugar de envolverlo en < > ¿señales?

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

Gracias de antemano!

Answer 1

En resumen:

iostream.h está en desuso: es la versión original de Stroustrup, e iostream es la versión del comité de estándares. En general, los compiladores apuntan a los dos a la misma cosa, pero algunos compiladores más antiguos no tendrán el más antiguo. En algunos casos extraños, ambos existirán y serán diferentes (para admitir el código heredado), por lo que deberá ser específico.

" " versus < > simplemente significa revisar los directorios locales para el encabezado antes de ir a la biblioteca (en la mayoría de los compiladores).

-Adam

Answer 2

Aquí hay un enlace decente artículo.

Para resumir, la razón dada:

  

La versión de la biblioteca de iostream que el Comité de Normas   producido fue un poco diferente de la implementación de CFront.   {recorte}

     

Para facilitar la transición, el Comité de Normas de C ++ declaró ese código   incluyendo los encabezados estándar de C ++ utilizarían las directivas que   Falta una extensión. Esto permitió a los proveedores de compiladores enviar el estilo antiguo   Encabezados de biblioteca C ++ con la extensión .h y los nuevos encabezados de estilo   sin.

Una ventaja de no usar la versión .h:

  

Hay varias razones por las que el nuevo código debe escribirse usando el   Versión sin extensión de los archivos de encabezado en lugar de los formularios .h. los   Lo primero es la impredecibilidad de dicho código cuando se compila en la versión moderna.   compiladores Como se mencionó anteriormente, el resultado de usar los encabezados .h   La implementación es específica. Y a medida que pasa el tiempo, la posibilidad de que un   el compilador dado tendrá la biblioteca de estilo antiguo disponible disminuye.

Answer 3

Como la persona en el comité de normas (X3J16) que propuso dejar de lado el .h, mi intención original era resolver el debate sobre las extensiones de archivo .h, .H, .hpp, .hxx o .h ++; o el deseo de algunos de que no haya ninguna implicación en el estándar de que este era el nombre de un archivo en el disco para permitir que un IDE extraiga información de encabezado precompilada de algún lugar interno como un archivo de recursos o incluso las agallas de compilador.

Si bien Unix consideraba que el nombre del archivo era una sola cadena y no reconocía realmente el concepto de una extensión, los sistemas operativos DEC tenían la tradición de separar el nombre de la extensión, y proporcionar la extensión predeterminada "quot." si se omitía en contextos particulares. De ahí surgió la idea de dejarlo en manos de la implementación para usar cualquier extensión que la implementación quisiera usar, y permitió que la implementación no tuviera ni siquiera un archivo en el disco. (Yo era el representante de DEC en el comité en ese momento).

La diferenciación entre los encabezados estándar y pre-estándar fue un beneficio adicional.

Answer 4

La forma estándar (y la única que se garantiza que funciona) es < iostream > ;. En gcc, < iostream.h > (que podría ser necesario incluir como < backward / iostream.h >) extrae las declaraciones relevantes al espacio de nombres global (por lo que no necesita el prefijo std :: namespace).

" iostream.h " probaría primero desde el directorio con su código fuente, ya que " " está destinado a los encabezados de su proyecto. < > siempre se debe utilizar para los encabezados del sistema, y ??" " para tus propios encabezados.

Answer 5

Normalmente, < > se utiliza para archivos de biblioteca estándar o del sistema, mientras que " " Se utiliza para archivos de proyecto. No me sorprendería si su compilador busca localmente y cuando no puede encontrarlo, por defecto es la versión estándar de la biblioteca.

En cuanto a .h, no creo que realmente importe si usas C. En C ++, recuerdo vagamente que había una versión más nueva y una versión más antigua y que sin la h se suponía que era la nueva versión, pero ni siquiera estoy seguro de que la versión anterior todavía exista.

Answer 6

Estas son realmente dos preguntas diferentes.

• La diferencia entre .h y encabezados sin extensión con el mismo El nombre es histórico. Los de la extensión .h son de la C ++ estándar original que no lo hizo tienen algunas características modernas como espacios de nombres y plantillas. Era Más simple para el nuevo estándar de poner Esa misma funcionalidad en la nueva. archivos de cabecera para poder utilizar estos Nuevas características y mantener las antiguas (.h). archivos para la compatibilidad hacia atrás de código heredado.

• La diferencia entre el #include < ... > y #include " ... " el formato es el orden en que el compilador busca archivos. Esto es generalmente dependiente de la implementación, pero la La idea es que el < > el formato se ve en El sistema incluye directorios primero, mientras que " " busca en el mismo directorio como el archivo fuente que # lo incluyó primero.

Answer 7

La respuesta simple a la primera respuesta es que iostream.h no existe, al menos en la implementación de GCC. Si estás en * nix, escribe

% ubica iostream.h
/usr/include/c++/3.4.3/backward/iostream.h

y

% encuentra iostream
/usr/include/c++/3.4.3/iostream
/usr/include/c++/3.4.3/backward/iostream.h

Como dice el artículo de Zee, iostream.h es para compatibilidad con versiones anteriores.

Answer 8

Con respecto a los nombres de los archivos de encabezado estándar de C ++, en los primeros días (primeros 2 años) de X3J16, enfrentamos un argumento sobre cuál debería ser la extensión en los archivos de encabezado estándar de C ++. En uso en ese momento por varios proveedores (e influenciado por las restricciones que algunos sistemas operativos colocaron en los nombres de archivo) creo que hubo .h, .H, .h ++, .hpp, .HXX y posiblemente otros. En una reunión de un grupo de bibliotecas, sugerí que dejáramos la extensión fuera, y la dejamos en la implementación para proporcionar una extensión de archivo predeterminada de su elección si no había ninguna en la línea de inclusión, o usar el nombre como clave en una base de datos de archivos de cabecera precompilados si se desea. [Mientras que los sistemas similares a Unix tratan el nombre de archivo y la 'extensión' como una sola cadena, representaba a DEC en el comité, y muchos sistemas operativos DEC almacenaron la extensión en el directorio como un campo separado del nombre. Así que los sistemas operativos DEC tenían una fuerte tradición de aplicar una extensión predeterminada basada en qué programa accedía al archivo con qué propósito. Decirle a un ensamblador 'X, Y = Z' podría resultar en la lectura del archivo de entrada Z.MAC (macro) y en la escritura de los archivos de salida X.OBJ y Y.LST.] De todos modos, se evitó un debate largo y sin ganancias, por lo que el grupo estuvo de acuerdo, y Andy Koenig presentó las conclusiones del grupo sobre esto (entre otros) a todo el comité que lo aceptó. Me parece algo divertido que las implementaciones no entendieron el punto de que podrían aplicar una extensión predeterminada de su elección (que creo que sería útil para los editores y otras herramientas) y simplemente dejaron la extensión fuera del nombre del archivo.