Eu uso .hpp porque quero que o utilizador diferencie os cabeçalhos que são cabeçalhos em C++, e os cabeçalhos que são cabeçalhos Em C.

Isto pode ser importante quando o seu projecto está a usar módulos C E C++: como alguém explicou antes de mim, deve fazê-lo com muito cuidado, e os seus começos pelo "contrato" que oferece através da extensão

.hpp: cabeçalhos em C++

(ou .hxx, or .hh, ou seja lá o que for)

Este cabeçalho é apenas para C++.

.h: cabeçalhos de C / C++ compatíveis ou puros

Este cabeçalho pode ser incluído tanto por uma fonte C como por uma fonte C++, directa ou indirectamente.

Pode ser incluído directamente, sendo protegido pela macro __cplusplus:

• o que significa que, de um ponto de vista C++, o código compatível com C será definido como extern "C".
• de um ponto de vista C, Todo o código C será claramente visível, mas o código C++ será escondido (porque não irá compilar num compilador C).

Por exemplo:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

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

#endif // MY_HEADER_H

Por exemplo:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

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

#endif // MY_HEADER_HPP

E:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

Sempre considerei o cabeçalho .hpp como uma espécie de conjunto de ficheiros .h e .cpp...um cabeçalho que contém detalhes de implementação também.

Normalmente, quando vejo (e uso) {[[0]} como uma extensão, não existe um ficheiro .cpp correspondente. Como outros já disseram, esta não é uma regra difícil e rápida, apenas como eu tendem a usar arquivos .hpp.

Não importa que Extensão use. Qualquer um está bem.

Eu uso *.h para C e *.hpp para C++.

Editar [sugestão adicionada de Dan Nissenbaum]:

Por uma convenção .arquivos hpp são usados quando os protótipos são definidos no cabeçalho em si. Tais definições em cabeçalhos são úteis no caso de modelos, uma vez que o compilador gera o código para cada tipo apenas em instanciação de modelo. Assim, se eles não forem definidos em arquivos de cabeçalho, suas definições não serão resolvidas no momento do link a partir de outras unidades de compilação. Se o seu projecto é apenas um projecto C++ que produz uso pesado de modelos, esta convenção pode ser útil.

Certas bibliotecas-modelo que aderem a esta convenção fornecem cabeçalhos .extensões hpp para indicar que eles não têm correspondente .ficheiros cpp.

Algumas outras bibliotecas-modelo usam outra convenção, como usar .h para cabeçalhos C e .hpp para C++; um bom exemplo seria a biblioteca boost.

Citação do Boost FAQ,

As extensões de Ficheiros comunicam o" tipo " do ficheiro, tanto para seres e aos programas de computador. O '.a extensão h' é usada para o cabeçalho C ficheiros, e portanto comunica a coisa errada sobre o cabeçalho C++ arquivo. Sem extensão não comunica nada e a inspecção das forças do conteúdo do arquivo para determinar o tipo. Mear '.hpp ' sem ambiguidade identifica-o como arquivo header C++, e funciona bem na prática real. (Rainer Deyke)

Comecei recentemente a usar *.hpp para cabeçalhos em C++.

A razão é que eu uso o emacs como meu editor primário e ele entra automaticamente no modo c quando carrega um ficheiro *.h e no modo c++quando carrega um ficheiro *.hpp.

Só preciso de especificar esse nome completo no {[[0]}.

Sugiro que, se trabalhar com C para usar .h e quando estiver com C++ para usar .hpp.

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

Ter ficheiros header com A.a extensão hpp não tem o mesmo fluxo lógico.

Assim como muitos já responderam: de qualquer maneira está bem. Seguido de enfatizar suas próprias impressões.

Introductive, como também nos comentários citados anteriormente, a minha opinião é C++ as extensões de cabeçalho são propostas para ser .h Se não houver realmente nenhuma razão contra isso.

Uma vez que os documentos ISO / IEC usam esta notação de ficheiros de cabeçalho e nenhuma cadeia de caracteres correspondente a {[5] } mesmo ocorre em suas documentações de linguagem sobre C++.

A documentação C++ (Estou de facto a tomar a resferência da versão N3690) define que um cabeçalho tem de estar em conformidade com a seguinte sintaxe:

2. 9 nomes de cabeçalho

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 "

Por outras palavras: se você tivesse um Filename de suporte envolvente como prettyStupidIdea.>, Um include como:

#include "prettyStupidIdea.>"

Seria válido, mas:

#include <prettyStupidIdea.>>

Seria inválido. O outro caminho na mesma.

O C++ permite qualquer coisa que respeite o parágrafo anterior. E se há alguma coisa que o Comitê propôs usar, então ele está usando .h uma vez que esta é a extensão processada em todos os exemplos do documento ISO.

Conclusão:

Desde que não veja/sinta qualquer necessidade de usar .h sobre .hpp ou vice-versa, não se deve incomodar. Porque ambos seriam um nome de cabeçalho Válido de mesma qualidade em relação ao padrão. E portanto, qualquer coisa que requeira que você use .h ou .hpp é uma restrição adicional do padrão que poderia mesmo estar contradizendo com outras restrições adicionais não estão em conformidade uns com os outros. Mas como o OP não menciona nenhuma restrição de linguagem adicional esta é a única resposta correta e aprovável para a pergunta

"*.h or *.hpp para as definições de classe " é:

Ambos são igualmente correctos e aplicáveis desde que não haja restrições externas. estão presentes.

¹_{claro que não posso dizer o que algumas versões futuras trarão com ele!}

Devias usar o .extensão hpp se você estiver trabalhando com C++ e você deve usar .h para C ou mistura de C e c++.

O CodeGear C++Builder usa .hpp para arquivos header gerados automagicamente a partir de arquivos fonte Delphi, e .h ficheiros para os seus ficheiros de cabeçalho "próprios".

Então, quando estou a escrever um ficheiro de cabeçalho C++ que uso sempre .h.

Bjarne Stroustrup e Herb Sutter têm uma declaração sobre esta questão nas suas directrizes principais de C++ encontradas em: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source que também se refere às últimas alterações na extensão padrão (C++11, C++14, etc.)

SF.1: Use a.sufixo cpp para ficheiros de código e .h para os ficheiros de interface se o seu O projecto Y já não segue outra convenção. Justificação

É uma longa história. convencao. Mas a consistência é mais importante, por isso se o teu projecto usa outra coisa, segue isso. Nota

Esta convenção reflecte um padrão de Utilização comum: os cabeçalhos são mais frequentemente partilhados com C para compilar tanto como C++ E C, que normalmente usa .h, E é é mais fácil nomear todos os cabeçalhos .h em vez de ter diferentes extensões para apenas os cabeçalhos que são destinados a ser compartilhados com C. Por outro lado, arquivos de implementação raramente são compartilhados com C e assim deve normalmente ser distinto de .arquivos em c, por isso é normalmente melhor nomear todos os C++ implementation files something else (such as .cpp).

Os nomes específicos .H and.cpp não são necessários (apenas recomendado como um padrão) e outros nomes estão em uso generalizado. Exemplos são .hh, .C, e .cxx. Use esses nomes de forma equivalente. Neste documento, referimo-nos .H and.cpp > como uma abreviatura para arquivos de cabeçalho e implementação, mesmo que o real a extensão pode ser diferente.

A sua IDE (se utilizar uma) pode ter opiniões fortes sobre o suficiente.

Eu não sou um grande fã desta Convenção porque se você está usando uma biblioteca popular como o boost, sua consistência já está quebrada e você deve usar melhor .hpp.

Como muitos aqui já mencionaram, eu também prefiro usar .hpp para as bibliotecas só para cabeçalhos que usam classes/funções de modelos. Prefiro usar .h para os ficheiros header acompanhados por .ficheiros de código cpp ou bibliotecas partilhadas ou estáticas.

A maioria das bibliotecas que eu desenvolvi são baseadas em modelos e, portanto, precisam ser apenas cabeçalho, mas ao escrever aplicações eu tendem a separar a declaração da implementação e acabar com .H and.ficheiros cpp

Eu uso .h porque é isso que a Microsoft usa, e o que o gerador de código deles cria. Não é preciso ir contra o cereal.

É fácil para Ferramentas e humanos diferenciar algo. É isso.

No uso convencional (por impulso, etc), .hpp é especificamente cabeçalhos em C++. Por outro lado, .h é para cabeçalhos não-C++(principalmente C). Para detectar com precisão a linguagem do conteúdo é geralmente difícil, uma vez que existem muitos casos não triviais, por isso esta diferença muitas vezes faz com que uma ferramenta pronta a usar seja fácil de escrever. Para os seres humanos, uma vez que a convenção, também é fácil de lembrar e fácil de usar.

• não é forçado pela especificação das linguagens, nem C nem C++. Existem muitos projectos que não seguem a Convenção. Uma vez que você precisa fundir (para misturar) eles, pode ser problemático.
• .hpp não é a única escolha. Porque não .hh ou .hxx? (De qualquer forma, você geralmente precisa de pelo menos uma regra convencional sobre nomes de arquivos e caminho.)

Uso pessoalmente tanto .h como .hpp nos meus projectos em C++. Eu não sigo a Convenção acima porque:

• as línguas utilizadas por cada parte dos projectos estão explicitamente documentadas. Não é possível misturar C E C++ no mesmo módulo (directório). Cada biblioteca 3rdparty é necessária para se conformar a esta regra.
• as especificações linguísticas em conformidade e os dialectos linguísticos autorizados utilizados pelos projectos também estão documentados. (De facto, até documento a origem das funcionalidades-padrão e da correcção de erros (na norma linguística) a ser utilizada.) Este é um pouco mais importante do que distinguir as línguas, pois é muito suscetível a erros e o custo do teste (e.g. compilador de compatibilidade) pode ser significativo (complicado e demorado, especialmente em um projeto que já está em quase puro C++. Os nomes dos ficheiros são demasiado fracos para lidar com isto.
• mesmo para o mesmo dialeto C++, pode haver propriedades mais importantes adequado à diferença. Por exemplo, veja a Convenção abaixo.
• os nomes dos ficheiros são essencialmente peças de metadados frágeis. A violação da Convenção não é tão fácil de detectar. Para ser estável a lidar com o conteúdo, uma ferramenta não deve depender apenas dos nomes. A diferença entre extensões é apenas uma dica. Também não se deve esperar que as ferramentas que o utilizam se comportem sempre da mesma forma, por exemplo, detecção de linguagem de ficheiros .h em github.com. (pode haver algo em comentários como shebang para estes ficheiros de código serem melhores metadados, mas nem sequer é convencional como nomes de ficheiros, por isso também não é fiável em geral.)

Normalmente uso .hpp em cabeçalhos de C++ e os cabeçalhos devem ser usados (mantidos) de uma forma apenas de cabeçalho, por exemplo como bibliotecas de modelos. Para outros cabeçalhos em .h, ou existe um ficheiro .cpp correspondente como implementação, ou é um cabeçalho não-C++. O último é trivial para diferenciar através do conteúdo do cabeçalho por humanos (ou por ferramentas com metadados incorporados explícitos, se necessário).

A extensão do arquivo de origem pode ter significado para o seu sistema de compilação, por exemplo, você pode ter uma regra em seu makefile para .cpp ou .c arquivos, ou seu compilador (por exemplo, Microsoft cl.exe) pode compilar o arquivo como C ou C++, dependendo da extensão.

Porque tem de indicar o nome completo do ficheiro à Directiva #include, a extensão do ficheiro de cabeçalho é irrelevante. Você pode incluir um arquivo .c em outro arquivo fonte, se quiser, porque é apenas uma inclusão textual. O seu compilador poderá ter uma opção para descarregar a saída pré-processada que tornará isto claro (Microsoft: /P para pré-processar Para ficheiro, /E para pré-processar para stdout, /EP para omitir #line as directivas, /C para manter os comentários)

Você pode optar por usar .hpp para ficheiros que só são relevantes para o ambiente C++, ou seja, usam funcionalidades que não irão compilar no C.

In "The C++ Programming Language, Third Edition by Bjarne Stroustrup", the nº1 must-read C++ book, he uses *.h. Então eu assumo que a melhor prática é usar *.h.

No entanto,*.hpp também está bem!

Não há vantagem para nenhuma extensão em particular, a não ser que uma pessoa pode ter um significado diferente para você, o compilador, e/ou suas ferramentas. header.h é um cabeçalho válido. header.hpp é um cabeçalho válido. header.hh é um cabeçalho válido. header.hx é um cabeçalho válido. h.header é um cabeçalho válido. this.is.not.a.valid.header é um cabeçalho válido em negação. ihjkflajfajfklaf é um cabeçalho válido. Desde que o nome possa ser processado corretamente pelo compilador, e o sistema de arquivos suporta-lo, é um cabeçalho válido, e a única vantagem para o seu a extensão é o que se lê nela.

Dito isto, ser capaz de fazer com precisão suposições com base na extensão é Muito útil, por isso seria sensato usar um conjunto de regras facilmente compreensível para os seus ficheiros de cabeçalho. Pessoalmente, prefiro fazer algo assim:

1. se já existem orientações estabelecidas, siga-as para evitar confusões.
2. se todos os ficheiros de código no projecto são para o mesmo idioma, use .h. Não há ambiguidade.
3. se alguns cabeçalhos são compatíveis com várias línguas, enquanto outros são apenas compatíveis com uma única língua, as extensões são baseadas na linguagem mais restritiva com a qual um cabeçalho é compatível. Um cabeçalho compatível com C ou com C & C++, obtém .h, enquanto um cabeçalho compatível com C++, mas não C obtém .hpp ou .hh ou algo do tipo.