c++ - son - *.h o*.hpp para tus definiciones de clase

metodos de conservacion de alimentos por presion

Question

Siempre he usado un archivo *.h para mis definiciones de clase, pero después de leer un código de biblioteca de impulso, me di cuenta de que todos usan *.hpp . Siempre he tenido una aversión a esa extensión de archivo, creo que principalmente porque no estoy acostumbrado.

¿Cuáles son las ventajas y desventajas de usar *.hpp sobre *.h ?

Answer 1

Afortunadamente, es simple.

Debería usar la extensión .hpp si está trabajando con C ++ y debería usar .h para C o mezclar C y C ++.

Answer 2

Aquí hay un par de razones para tener diferentes nombres de encabezados C vs C ++:

• Formato de código automático, es posible que tenga diferentes pautas para el formato de código C y C ++. Si los encabezados están separados por extensión, puede configurar su editor para que aplique el formato apropiado automáticamente
• Nombrando, he estado en proyectos donde había bibliotecas escritas en C y luego las envolturas se habían implementado en C ++. Dado que los encabezados usualmente tenían nombres similares, es decir, Feature.h vs Feature.hpp, eran fáciles de distinguir.
• Inclusión, tal vez su proyecto tenga disponibles versiones más apropiadas escritas en C ++ pero está utilizando la versión C (vea el punto anterior). Si los encabezados llevan el nombre del lenguaje en el que están implementados, puede detectar fácilmente todos los encabezados C y verificar las versiones de C ++.

Recuerde, C no es C ++ y puede ser muy peligroso mezclar y combinar a menos que sepa lo que está haciendo. Nombrar sus fuentes adecuadamente le ayuda a distinguir los idiomas.

Answer 3

Bjarne Stroustrup y Herb Sutter tienen una declaración a esta pregunta en sus directrices básicas de C ++ que se encuentran en: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source que también se refiere a los últimos cambios en la extensión estándar (C ++ 11, C ++ 14, etc.)

SF.1: use un sufijo .cpp para los archivos de código y .h para los archivos de interfaz si su proyecto Y no sigue otra convención. Razón

Es una convención de larga data. Pero la consistencia es más importante, así que si tu proyecto usa algo más, sigue eso. Nota

Esta convención refleja un patrón de uso común: los encabezados se comparten más a menudo con C para compilar como C ++ y C, que generalmente usa .h, y es más fácil nombrar todos los encabezados .h en lugar de tener diferentes extensiones solo para aquellos encabezados que están destinados para compartir con C. Por otro lado, los archivos de implementación rara vez se comparten con C y, por lo tanto, normalmente se deben distinguir de los archivos .c, por lo que normalmente es mejor nombrar todos los archivos de implementación de C ++ de otra forma (como .cpp).

Los nombres específicos .h y .cpp no ​​son obligatorios (solo se recomiendan por defecto) y otros nombres son de uso generalizado. Los ejemplos son .hh, .C y .cxx. Utilice dichos nombres de manera equivalente. En este documento, nos referimos a .h y .cpp> como una forma abreviada de los archivos de encabezado e implementación, aunque la extensión real puede ser diferente.

Su IDE (si usa uno) puede tener opiniones fuertes acerca de lo suficiente.

No soy un gran fan de esta convención porque si está utilizando una biblioteca popular como boost, su consistencia ya está rota y debería usar mejor .hpp.

Answer 4

C ++ ("C Plus Plus") tiene sentido como .cpp

Tener archivos de encabezado con una extensión .hpp no ​​tiene el mismo flujo lógico.

Answer 5

Codegear C ++ Builder utiliza .hpp para los archivos de encabezado generados automáticamente a partir de los archivos fuente de Delphi, y los archivos .h para sus archivos de encabezado "propios".

Entonces, cuando estoy escribiendo un archivo de encabezado de C ++ siempre uso .h.

Answer 6

Como muchos ya han mencionado, también prefiero usar .hpp para las bibliotecas de encabezado que usan funciones / clases de plantillas. Prefiero usar .h para archivos de encabezado acompañados de archivos de origen .cpp o bibliotecas compartidas o estáticas.

La mayoría de las bibliotecas que desarrollo están basadas en plantillas y, por lo tanto, solo necesitan encabezado, pero cuando escribo aplicaciones tiendo a separar la declaración de la implementación y terminar con archivos .h y .cpp

Answer 7

En "El lenguaje de programación C ++, tercera edición de Bjarne Stroustrup", el libro nº1 de C ++ que debe leerse, usa * .h. Entonces asumo que la mejor práctica es usar * .h.

Sin embargo, * .hpp también está bien!

Answer 8

En uno de mis trabajos a principios de los 90, usamos .cc y .hh para los archivos de fuente y de encabezado respectivamente. Todavía lo prefiero a todas las alternativas, probablemente porque es más fácil de escribir.

Answer 9

Es fácil para las herramientas y los humanos diferenciar algo . Eso es.

En uso convencional (por impulso, etc.), .hpp es específicamente encabezados de C ++. Por otro lado, .h es para encabezados que no son C ++, solo (principalmente C). Detectar con precisión el lenguaje del contenido es generalmente difícil ya que hay muchos casos no triviales, por lo que esta diferencia a menudo hace que una herramienta lista para usar sea fácil de escribir. Para los humanos, una vez que se obtiene la convención, también es fácil de recordar y de usar.

Sin embargo, me gustaría señalar que la convención en sí no siempre funciona, como se esperaba.

• No es forzado por la especificación de lenguajes , ni C ni C ++. Existen muchos proyectos que no siguen la convención. Una vez que necesites combinarlos (mezclarlos), puede ser problemático.
• .hpp sí no es la única opción. ¿Por qué no .hh o .hxx ? (Aunque de todos modos, normalmente necesita al menos una regla convencional sobre los nombres de archivo y las rutas).

Personalmente uso tanto .h como .hpp en mis proyectos de C ++. No sigo la convención anterior porque:

• Los idiomas utilizados por cada parte de los proyectos están documentados explícitamente. No hay posibilidad de mezclar C y C ++ en el mismo módulo (directorio). Cada biblioteca de terceros debe cumplir esta regla.
• Las especificaciones de idioma conformado y los dialectos de idioma permitidos utilizados por los proyectos también están documentados. (De hecho, incluso documento la fuente de las características estándar y la corrección de errores (en el estándar de idioma) que se está utilizando ). Esto es algo más importante que distinguir los idiomas utilizados, ya que es demasiado propenso a errores y el costo de la prueba (por ejemplo, la compatibilidad del compilador) puede ser significativa (complicada y requiere mucho tiempo), especialmente en un proyecto que ya está en C ++ casi puro . Los nombres de archivo son demasiado débiles para manejar esto.
• Incluso para el mismo dialecto C ++, puede haber propiedades más importantes adecuadas a la diferencia. Por ejemplo, vea la convención a continuación.
• Los nombres de archivo son esencialmente piezas de metadatos frágiles. La violación de la convención no es tan fácil de detectar. Para que el contenido sea estable, una herramienta eventualmente no solo debe depender de los nombres. La diferencia entre extensiones es solo una pista. Tampoco se debe esperar que las herramientas que lo utilizan se comporten igual todo el tiempo, por ejemplo, la detección de idioma de los archivos .h en github.com. (Puede haber algo en comentarios como shebang para que estos archivos de origen sean mejores metadatos, pero incluso no es convencional como los nombres de archivo, por lo que tampoco es confiable en general).

Normalmente uso .hpp en los encabezados de C ++ y los encabezados se deben usar (mantener) de forma exclusiva , por ejemplo, como bibliotecas de plantillas. Para otros encabezados en .h , o hay un archivo .cpp correspondiente como implementación, o es un encabezado que no es C ++. Este último es trivial para diferenciar a través del contenido del encabezado por humanos (o por herramientas con metadatos explícitos incrustados, si es necesario).

Answer 10

Estoy respondiendo esto como un recordatorio, para señalar mi (s) comentario (s) sobre la respuesta de "user1949346" a este mismo OP.

Así que como muchos ya respondieron: de cualquier manera está bien. Seguido por el énfasis de sus propias impresiones.

Introductivo, como también se mencionó en los comentarios nombrados, mi opinión es que las extensiones de encabezado de C++ se proponen como .h si en realidad no hay razón para ello.

Dado que los documentos ISO / IEC utilizan esta notación de archivos de encabezado y no se produce ninguna coincidencia de cadena con .hpp en sus documentaciones de idioma sobre C++ .

Pero ahora apunto por una buena razón por la que POR QUÉ está bien, y especialmente por qué no está sujeto al lenguaje en sí mismo.

Así que, aquí vamos.

La documentación de C++ (en realidad estoy tomando una referencia de la versión N3690) define que un encabezado debe cumplir con la siguiente sintaxis:

2.9 Nombres de encabezados

header-name:
    < h-char-sequence >
    " q-char-sequence "
h-char-sequence:
    h-char
    h-char-sequence h-char
h-char:
    any member of the source character set except new-line and >
q-char-sequence:
    q-char
    q-char-sequence q-char
q-char:
    any member of the source character set except new-line and "

Así que, como podemos extraer de esta parte, el nombre del archivo de audición también puede ser válido en el código fuente. Excepto que contenga caracteres ''/n'' y dependiendo de si se va a incluir por <> no está permitido contener un > . O de lo contrario, si está incluido por "" -include no está permitido contener una " .

En otras palabras: si tienes un entorno compatible con archivos como prettyStupidIdea.> , Incluye como:

#include "prettyStupidIdea.>"

Sería válido, pero:

#include <prettyStupidIdea.>>

sería inválido La otra manera alrededor de la misma.

Como el nombre del archivo ya lo explica, incluso esto sería conforme a C++ , sería una idea bastante estúpida.

Y es por eso que .hpp es válido.

¡Pero no un resultado del comité que diseña el lenguaje!

Por lo tanto, discutir sobre el uso de .hpp es lo mismo que hacerlo sobre .cc , .mm o cualquier otra cosa que haya leído en otras publicaciones sobre este tema.

Tengo que admitir que no tengo ni idea de dónde vino .hpp , pero apostaría a un inventor de alguna herramienta de análisis, IDE o alguna otra cosa relacionada con C++ llegó a esta idea para optimizar algunos procesos internos o simplemente para inventar algunos (probablemente incluso necesariamente). ) nuevas convenciones de nomenclatura.

Pero no es parte del lenguaje.

Y cada vez que uno decide usarlo de esta manera. Que sea porque a él le gusta más o porque algunas aplicaciones del flujo de trabajo lo requieren, nunca es un requisito del lenguaje. Entonces, quien dice "el pp es porque se usa con C ++", simplemente está mal.

C ++ permite cualquier cosa respetando el párrafo anterior. Y si hay algo que el comité propuso usar, entonces está usando .h ya que esta es la extensión demandada en todos los ejemplos del documento ISO.

Conclusión:

Mientras no veas / sientas la necesidad de usar .h sobre .hpp o viceversa, no debes molestarte. Porque ambos formarían un nombre de encabezado válido de la misma calidad con respecto al estándar. Y, por lo tanto, cualquier cosa que le .hpp usar .h o .hpp es una restricción adicional de la norma que incluso podría estar en contradicción con otras restricciones adicionales que no se ajustan entre sí. Pero como OP no menciona ninguna restricción de idioma adicional, esta es la única respuesta correcta y apropiada para la pregunta

" * .h o * .hpp para tus definiciones de clase " es:

Ambos son igualmente correctos y aplicables siempre que no haya restricciones externas.

^{1 Por} _{supuesto, no puedo decir lo que traerán algunas versiones futuras.}

Answer 11

La extensión del archivo de origen puede tener un significado para su sistema de compilación, por ejemplo, puede tener una regla en su makefile para archivos .cpp o .c , o su compilador (por ejemplo, Microsoft cl.exe ) puede compilar el archivo como C o C ++ dependiendo de la extensión.

Debido a que debe proporcionar todo el nombre del archivo a la directiva #include , la extensión del archivo de encabezado es irrelevante. Si lo desea, puede incluir un archivo .c en otro archivo de origen, porque es solo una inclusión textual. Su compilador podría tener una opción para volcar el resultado preprocesado que lo aclarará (Microsoft: /P para preprocesar en archivo, /E para preprocesar en stdout , /EP para omitir #line directivas #line , /C para retener los comentarios)

Puede elegir usar .hpp para los archivos que solo son relevantes para el entorno C ++, es decir, usan características que no se compilan en C.

Answer 12

No hay ninguna ventaja para ninguna extensión en particular, aparte de que una puede tener un significado diferente para usted, el compilador y / o sus herramientas. header.h es un encabezado válido. header.hpp es un encabezado válido. header.hh es un encabezado válido. header.hx es un encabezado válido. h.header es un encabezado válido. this.is.not.a.valid.header es un encabezado válido en negación. ihjkflajfajfklaf es un encabezado válido. Siempre que el compilador pueda analizar el nombre correctamente y que el sistema de archivos lo admita, es un encabezado válido, y la única ventaja de su extensión es lo que uno lee en él.

Dicho esto, ser capaz de hacer suposiciones con precisión en función de la extensión es muy útil, por lo que sería conveniente utilizar un conjunto de reglas fácilmente comprensibles para sus archivos de encabezado. Personalmente, prefiero hacer algo como esto:

1. Si ya existen pautas establecidas, sígalas para evitar confusiones.
2. Si todos los archivos de origen en el proyecto son para el mismo idioma, use .h . No hay ambigüedad.
3. Si algunos encabezados son compatibles con varios idiomas, mientras que otros solo son compatibles con un solo idioma, las extensiones se basan en el idioma más restrictivo con el que es compatible un encabezado. Un encabezado compatible con C, o con C y C ++, obtiene .h , mientras que un encabezado compatible con C ++ pero no C obtiene .hpp o .hh o algo por el estilo.

Esto, por supuesto, es solo una de las muchas formas de manejar las extensiones, y no necesariamente puede confiar en su primera impresión, incluso si las cosas parecen sencillas. Por ejemplo, he visto la mención de usar .h para los encabezados normales, y .tpp para los encabezados que solo contienen definiciones para las funciones miembro de la clase con plantilla, con archivos .h que definen las clases con plantilla incluyendo los archivos .tpp que definen sus funciones miembro ( en lugar del encabezado .h que contiene directamente la declaración de la función y la definición). Por otro ejemplo, muchas personas siempre reflejan el lenguaje del encabezado en su extensión, incluso cuando no hay posibilidad de ambigüedad; para ellos, .h siempre es un encabezado C y .hpp (o .hh , o .hxx , etc.) siempre es un encabezado C ++. Y una vez más, algunas personas usan .h para "encabezado asociado con un archivo fuente" y .hpp para "encabezado con todas las funciones definidas en línea".

Teniendo en cuenta esto, la principal ventaja vendría consistentemente al nombrar sus encabezados en el mismo estilo y hacer que ese estilo sea evidente para cualquiera que examine su código. De esta manera, cualquier persona familiarizada con su estilo de codificación habitual podrá determinar qué quiere decir con cualquier extensión dada con solo una simple mirada.

Answer 13

No importa qué extensión uses. Cualquiera de los dos está bien.

Yo uso *.h para C y *.hpp para C ++.

Answer 14

Prefiero .hpp para C ++ para dejar en claro a ambos editores y a otros programadores que es un encabezado de C ++ en lugar de un archivo de encabezado de C.

Answer 15

Puede llamar a su incluye lo que quieras.

Solo necesita especificar ese nombre completo en el #include .

Sugiero que si trabajas con C para usar .h y cuando con C ++ para usar .hpp .

Es al final solo una convención.

Answer 16

Recientemente comencé a usar *.hpp para los *.hpp de c ++.

La razón es que uso emacs como mi editor principal y entra automáticamente en modo c cuando carga un archivo *.h y en modo c ++ cuando carga un archivo *.hpp .

Aparte de eso, no veo buenas razones para elegir *.h sobre *.hpp o viceversa.

Answer 17

Siempre consideré que el encabezado .hpp era una especie de .cpp archivos .h y .cpp ... un encabezado que también contiene detalles de implementación.

Normalmente, cuando veo (y uso) .hpp como una extensión, no hay .cpp archivo .cpp correspondiente. Como han dicho otros, esto no es una regla difícil y rápida, simplemente cómo tiendo a usar los archivos .hpp .

Answer 18

Uso .h porque eso es lo que usa Microsoft y lo que crea su generador de código. No hay necesidad de ir contra el grano.

Answer 19

Utilizo .hpp porque quiero que el usuario distinga qué encabezados son encabezados C ++ y qué encabezados son encabezados C.

Esto puede ser importante cuando su proyecto usa módulos C y C ++: como lo explicó alguien más antes que yo, debe hacerlo con mucho cuidado, y comienza por el "contrato" que ofrece a través de la extensión

.hpp: Encabezados C ++

(O .hxx, o .hh, o lo que sea)

Este encabezado es solo para C ++.

Si estás en un módulo C, ni siquiera intentes incluirlo. No le va a gustar, porque no se hace ningún esfuerzo para que sea compatible con C (se perdería demasiado, como la sobrecarga de funciones, espacios de nombres, etc.).

.h: Cabezales C o C ++ compatibles o puros

Este encabezado puede ser incluido tanto por una fuente en C, como por una fuente en C ++, directa o indirectamente.

Puede incluirse directamente, estando protegido por la macro __cplusplus :

• Lo que significa que, desde un punto de vista de C ++, el código compatible con C se definirá como extern "C" .
• Desde un punto de vista de C, todo el código de C será claramente visible, pero el código de C ++ estará oculto (porque no se compilará en un compilador de C).

Por ejemplo:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

   #ifdef __cplusplus
      } // extern "C"
   #endif

#endif // MY_HEADER_H

O podría ser incluido indirectamente por el encabezado correspondiente .hpp que lo encierra con la declaración extern "C" .

Por ejemplo:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

extern "C"
{
#include "my_header.h"
}

#endif // MY_HEADER_HPP

y:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

Answer 20

EDITAR [sugerencia añadida de Dan Nissenbaum]:

Según una convención, los archivos .hpp se utilizan cuando los prototipos se definen en el encabezado. Dichas definiciones en los encabezados son útiles en el caso de las plantillas, ya que el compilador genera el código para cada tipo solo en la creación de instancias de la plantilla. Por lo tanto, si no están definidos en archivos de cabecera, sus definiciones no se resolverán en el momento del enlace desde otras unidades de compilación. Si su proyecto es solo un proyecto en C ++ que hace un uso intensivo de plantillas, esta convención podría ser útil.

Ciertas bibliotecas de plantillas que se adhieren a esta convención proporcionan encabezados con extensiones .hpp para indicar que no tienen los archivos .cpp correspondientes.

Algunas otras bibliotecas de plantillas usan otra convención, como usar .h para encabezados C y .hpp para C ++; Un buen ejemplo sería la biblioteca boost.

Cita de Boost FAQ,

Las extensiones de archivo comunican el "tipo" del archivo, tanto a personas como a programas informáticos. La extensión ''.h'' se usa para los archivos de encabezado C y, por lo tanto, comunica algo incorrecto sobre los archivos de encabezado C ++. El uso de ninguna extensión no comunica nada y obliga a la inspección del contenido del archivo para determinar el tipo. El uso de ''.hpp'' lo identifica de forma inequívoca como archivo de encabezado de C ++ y funciona bien en la práctica real. (Rainer Deyke)