¿cuál es la diferencia entre hpp y hxx?

Question

para gcc deberían ser iguales, ¿verdad? cuál de ellos es más popular, ahora estoy preparando un proyecto desde cero y me gustaría que elegir uno entre estos 2.

gracias

Answer 1

En C++, la extensión del archivo en realidad no importa. El uso de .h, .hpp, .hxx o ninguna extensión de archivo es todo por convención.

La biblioteca estándar no utiliza ninguna extensión de archivo para sus archivos de encabezado. Muchos proyectos, incluido Boost, usan .hpp. Muchos proyectos usan .h. Solo elija uno y sea consistente en su proyecto.

Answer 2

Las extensiones de archivos de encabezado generalmente no hacen la diferencia, pero sé que en algunos casos la extensión del archivo .cpp puede hacer la diferencia. Dependiendo de su compilador, el front-end puede optar por compilar el archivo fuente como C o C++.

Esto puede marcar la diferencia, especialmente si combina la compilación con la fase de enlace, ya que puede conducir a diferentes bibliotecas vinculadas (por ejemplo, g ++ frente a gcc) y así puede controlar el resultado en su archivo MAKE.

Answer 3

El compilador no distingue entre las dos extensiones, por lo que técnicamente no importa cuál use. Personalmente utilizo la extensión .hxx para los archivos de encabezado que solo se usan internamente en el proyecto, y .hpp para los que deberían publicarse con la biblioteca/el software.

Answer 4

Propongo que volvamos a abrir esta discusión, en vista de un descubrimiento reciente que hice. Durante los últimos 9 años, he utilizado la siguiente convención de nomenclatura para los archivos fuente en mis proyectos C y C++.

• C código fuente = Recta C, que contiene uno o puntos de entrada más relacionados
código fuente
• CPP = C++, que contiene uno o más relacionados puntos de entrada
• H = Declaración de funciones, macros, estructuras, typedefs , etc.
• INL = Inline (cuerpos de las funciones) que son los cuerpos de dos o más funciones cuyo archivo de definición principal es un archivo de C o CPP, en los que se incorporan por #include

un ejemplo de t Estos cuerpos de funciones comunes, MyStringFunctionA, la implementación ANSI, se definen en MyStringFunctionA.cpp, mientras que MyStringFunctionW, la implementación Unicode (caracteres anchos), se define en MyStringFunctionW.cpp. MyStringFunctionA.cpp y MyStringFunctionW.cpp contienen el prototipo, los corchetes de apertura y cierre y los encabezados, sujetos a UNICODE para la versión de caracteres anchos. El cuerpo de la función se define en el archivo INI, que es #incluido en línea, dentro del bloque de definición de función.

Combinado con las asignaciones genéricas de TCHAR, este enfoque simplifica en gran medida el mantenimiento de las versiones de Unicode y ANSI, que permanecen en uso activo.

Esta convención de nomenclatura funcionaba muy bien con Visual Studio 6. Sin embargo, cuando comencé a migrar mi base de código a Visual Studio 2013, descubrí un cambio molesto que inicialmente era confuso. Aunque todo se compiló limpiamente, cuando uno de mis archivos INL estaba abierto en el editor de código, veía decenas de "errores" de Intellisense listados en la ventana de Errores. Cité el término "errores" porque no son verdaderos errores; desaparecen cuando se cierra el archivo INL, y los archivos C y CPP en los que se extrae el iNL se compilan sin errores, se enlazan y se ejecutan correctamente.