Używam .hpp, ponieważ chcę, aby użytkownik odróżnił co nagłówki są C++ nagłówki, a co nagłówki są C nagłówki.

Może to być ważne, gdy twój projekt używa zarówno modułów C, jak i c++: jak ktoś inny wyjaśnił mi, powinieneś zrobić to bardzo ostrożnie, a jego początek zaczyna się od "umowy", którą oferujesz poprzez rozszerzenie

.hpp: C++ Headers

(albo .hxx, lub .hh, czy jakoś tak)

Ten nagłówek jest tylko dla C++.

If you ' re in A C moduł, nawet nie próbuj tego włączać. Nie spodoba ci się to, ponieważ nie robi się żadnego wysiłku, aby uczynić go przyjaznym dla C (zbyt wiele byłoby straconych, takich jak przeciążenie funkcji, przestrzenie nazw itp. itd.).

.h: c / c++ compatible or pure C Headers

Ten nagłówek może być dołączony zarówno przez źródło C, jak i źródło C++, bezpośrednio lub pośrednio.

Może zawierać bezpośrednio, jest chroniony przez makro __cplusplus:

• co oznacza, że z punktu widzenia C++ kod zgodny z C będzie zdefiniowana jako extern "C".
• Z punktu widzenia C, cały kod C będzie wyraźnie widoczny, ale kod C++ będzie ukryty (ponieważ nie będzie kompilowany w kompilatorze C).

Na przykład:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

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

#endif // MY_HEADER_H

Lub może być włączone pośrednio przez odpowiednie .nagłówek hpp zamykający go deklaracją extern "C".

Na przykład:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

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

#endif // MY_HEADER_HPP

I:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

Zawsze uważałem nagłówek .hpp za rodzaj portmanteau plików .h i .cpp...nagłówek zawierający szczegóły implementacji.

Zazwyczaj gdy widziałem (i używam) .hpp jako rozszerzenia, nie ma odpowiedniego pliku .cpp. Jak mówili inni, nie jest to trudna i szybka zasada, tylko jak zwykle używam plików .hpp.

Nie ma znaczenia, którego rozszerzenia użyjesz. Oba są w porządku.

Używam *.h dla C i *.hpp dla C++.

EDIT [dodany przez Dan Nissenbaum]:

Przez jedną konwencję, .pliki hpp są używane, gdy prototypy są zdefiniowane w samym nagłówku. Takie definicje w nagłówkach są przydatne w przypadku szablonów, ponieważ kompilator generuje kod dla każdego typu tylko przy instancjacji szablonu. W związku z tym, jeśli nie są one zdefiniowane w plikach nagłówkowych, ich definicje nie będą rozwiązywane w czasie łącza z innych jednostek kompilacji. Jeśli twój projekt jest tylko projektem C++, który sprawia, że ciężkie użycie szablonów, ta konwencja może być przydatna.

Niektóre biblioteki szablonów, które są zgodne z tą konwencją, zawierają nagłówki .rozszerzenia hpp, aby wskazać, że nie mają odpowiednika .pliki cpp.

Niektóre inne biblioteki szablonów używają innej konwencji, np. using .h jak C nagłówki i .hpp dla C++; dobrym przykładem może być Biblioteka boost.

Cytat z Boost FAQ,

Rozszerzenia plików komunikują" Typ " pliku, zarówno ludziom i do programów komputerowych. ".rozszerzenie h ' służy do nagłówka C plików, a tym samym komunikuje się źle z nagłówkiem C++ pliki. Użycie bez rozszerzenia nic nie komunikuje i wymusza inspekcję zawartości pliku w celu określenia typu. Using".hpp" identyfikuje go jako plik nagłówkowy C++ i działa dobrze w rzeczywistej praktyce. (Rainer Deyke)

Ostatnio zacząłem używać *.hpp dla nagłówków c++.

Powodem jest to, że używam Emacsa jako głównego edytora I wchodzi on automatycznie w tryb c po załadowaniu pliku *.h i w tryb c++po załadowaniu pliku *.hpp.

Poza tym faktem nie widzę dobrych powodów do wyboru *.h nad *.hpp lub odwrotnie.

W jednej z moich prac na początku lat 90-tych, użyliśmy .cc i .hh odpowiednio dla plików źródłowych i nagłówkowych. Nadal wolę go od wszystkich alternatyw, prawdopodobnie dlatego, że najłatwiej jest pisać.

Wolę .hpp dla C++, aby wyjaśnić zarówno redaktorom, jak i innym programistom, że jest to nagłówek C++, a nie plik nagłówka C.

Możesz nazywać swoje includes, jak chcesz.

Wystarczy podać pełną nazwę w #include.

Sugeruję, że jeśli pracujesz z C używać {[1] } i kiedy Z C++ używać .hpp.

C++ ("C Plus Plus") ma sens jako .cpp

Posiadanie plików nagłówkowych zrozszerzenie hpp nie ma takiego samego logicznego przepływu.

[[26]} odpowiadam na to jako przypomnienie, aby wskazać mój komentarz(y) na "user1949346" odpowiedź na to samo OP.

Więc jak wielu już odpowiedział: tak czy inaczej jest w porządku. Następnie podkreślają własne wrażenia.

Wprowadzenie, jak również w privious nazwane komentarze podane, moim zdaniem C++ rozszerzenia nagłówka są proponowane .h Jeśli nie ma rzeczywiście powodu przeciwko nim.

Ponieważ dokumenty ISO / IEC używają tej notacji plików nagłówkowych i nie string pasujący do .hpp występuje nawet w ich dokumentacji językowej o C++.

Ale teraz dążę do akceptowalnego powodu, dlaczego eitherway jest ok, a zwłaszcza dlaczego nie jest przedmiotem języka, który sam.

Dokumentacja C++ (w rzeczywistości biorę referencję z wersji N3690) definiuje nagłówek musi być zgodna z następującą składnią:

2.9 nazwy nagłówków

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 "

Tak jak możemy wydobyć z ta część jest nazwą hearfile może być cokolwiek, co jest poprawne w kodzie źródłowym. Z wyjątkiem znaków {[8] } i w zależności od tego, czy ma być dołączony przez <>, nie może zawierać >. Lub w inny sposób, jeśli jest dołączony przez "" - include nie może zawierać ".

W otherwords: jeśli masz środowisko wspierające filenamse jak prettyStupidIdea.>, include jak:

#include "prettyStupidIdea.>"

Byłoby ważne, ale:

#include <prettyStupidIdea.>>

Byłoby nieważne. The otherway mniej więcej tak samo.

Jak już sama nazwa pliku wyjaśnia, nawet to byłoby zgodne z C++, byłby to dość głupi pomysł.

I dlatego .hpp jest również ważna.

Ale nie wynik Komitetu projektowania języka!

Więc dyskutowanie o użyciu .hpp jest tym samym, co robienie tego o .cc, .mm albo co innego czytałem w innych postach na ten temat.

Muszę przyznać, że nie mam pojęcia skąd .hpp się wzięło, ale postawiłbym na wynalazca jakiegoś narzędzia do parsowania, IDE lub czegoś innego związanego z C++ wpadł na ten pomysł, aby zoptymalizować niektóre wewnętrzne procesy lub po prostu wymyślić niektóre (prawdopodobnie nawet konieczne) nowe nazewnictwo-konwencje.

Ale to nie jest część języka.

I zawsze, gdy ktoś zdecyduje się użyć go w ten sposób. Może to dlatego, że lubi go najbardziej lub dlatego, że niektóre aplikacje workflow tego wymagają, nigdy¹ jest wymogiem języka. Więc kto mówi " pp jest bo to jest używany z C++", po prostu jest źle.

C++ pozwala na wszystko, co jest zgodne z poprzednim akapitem. A jeśli jest coś, co Komitet proponował użyć, to używa .h, ponieważ jest to rozszerzenie we wszystkich przykładach dokumentu ISO.

Wniosek:

Dopóki nie widzisz/nie czujesz potrzeby używania .h przez .hpp lub imadła versa, nie powinieneś się martwić. Ponieważ oba byłyby poprawną nazwą nagłówka o tej samej jakości w odniesieniu do standardu. Oraz dlatego wszystko, co wymaga do użycia .h lub .hpp jest dodatkowym ograniczeniem standardu, które może być nawet sprzeczne z innymi dodatkowymi ograniczeniami, które nie są ze sobą zgodne. Ale ponieważ OP nie wspomina o żadnych dodatkowych ograniczeniach językowych, jest to jedyna poprawna i przystępna odpowiedź na pytanie

"*.h lub *.hpp for your class definitions " to:

Oba są jednakowo poprawne i mają zastosowanie, dopóki nie ma zewnętrznych ograniczeń są obecne.

¹_{oczywiście nie mogę powiedzieć, co niektóre przyszłe wersje przyniosą ze sobą!}

Na szczęście jest to proste.

Powinieneś użyć .rozszerzenie hpp jeśli pracujesz z C++ i powinieneś używać .h jak C lub mieszanie C i C++.

Codegear C++Builder używa .hpp dla plików nagłówkowych generowanych automatycznie z plików źródłowych Delphi oraz .pliki h dla" własnych " plików nagłówkowych.

Więc, kiedy piszę plik nagłówkowy C++ zawsze używam .h.

Bjarne Stroustrup i Herb Sutter mają oświadczenie na to pytanie w ich C++ Core guidelines znaleźć na: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source , który odnosi się również do najnowszych zmian w standardowym rozszerzeniu (C++11, C++14, itd.)

SF.1: Użyj a .przyrostek cpp dla plików kodu i .h dla plików interfejsu, jeśli twój Projekt Y nie jest już zgodny z inną konwencją Reason

To od dawna zjazd. Ale spójność jest ważniejsza, więc jeśli Twój projekt używa czegoś innego, postępuj zgodnie z tym. Uwaga

Ta konwencja odzwierciedla wspólny wzorzec użycia: nagłówki są częściej współdzielone z C, aby skompilować zarówno C++ , jak i C, który zazwyczaj używa .h, i to łatwiej nazwać wszystkie nagłówki .h zamiast mieć różne rozszerzenia dla tylko te nagłówki, które mają być współdzielone z C. z drugiej strony, pliki implementacyjne rzadko są współdzielone z C i dlatego powinny zazwyczaj być wyróżniony .plików c, więc normalnie najlepiej nazwać wszystkie C++ pliki implementacyjne coś innego (np.cpp).

Nazwy szczegółowe .h i .cpp nie są wymagane (tylko zalecane jako domyślne) i inne nazwy są w powszechnym użyciu. Przykładami sąhh, .C, oraz .cxx. Używaj takich nazw równoważnie. W tym dokumencie odwołujemy się do .h i .cpp > jako skrót dla plików nagłówkowych i implementacyjnych, mimo że rzeczywista rozszerzenie może być inne.

Twój IDE (jeśli go używasz) może mieć silne opinie na temat wystarczalności.

Nie jestem wielkim fanem tej konwencji, ponieważ jeśli używasz popularnej biblioteki, takiej jak boost, twoja konsystencja jest już zepsuta i powinieneś lepiej jej używać .hpp.

Jak wielu tutaj już wspomniało, ja również wolę używać .hpp dla bibliotek tylko nagłówkowych, które używają klas/funkcji szablonu. Wolę używać .h dla plików nagłówkowych, którym towarzyszy .pliki źródłowe cpp lub biblioteki współdzielone lub statyczne.

Większość bibliotek, które tworzę, jest oparta na szablonach i dlatego muszą być tylko nagłówkami, ale pisząc aplikacje mam tendencję do oddzielania deklaracji od implementacji i kończenia z .h i .pliki cpp

Używam .h bo tego używa Microsoft i co tworzy ich generator kodu. Nie musisz iść pod prąd.

Łatwo jest narzędziom i ludziom odróżnić coś . To wszystko.

W konwencjonalnym użyciu (przez boost, etc), {[0] } jest specjalnie C++ nagłówki. Z drugiej strony, {[1] } jest dla nagłówków innych niż c++(głównie C). Dokładne wykrycie języka treści jest na ogół trudne, ponieważ istnieje wiele nietrywialnych przypadków, więc ta różnica często sprawia, że gotowe narzędzie jest łatwe do napisania. Dla ludzi, po uzyskaniu konwencji, jest to również łatwe do zapamiętania i łatwe do użyj.

Chciałbym jednak zaznaczyć, że sama Konwencja nie zawsze działa, zgodnie z oczekiwaniami.

• nie jest wymuszona przez specyfikację języków , ani C, ani c++. Istnieje wiele projektów, które nie są zgodne z konwencją. Gdy trzeba je połączyć (aby wymieszać), może to być kłopotliwe.
• .hpp sama w sobie nie jest jedynym wyborem. Dlaczego nie .hh lub .hxx? (Chociaż w każdym razie, zwykle potrzebujesz co najmniej jednej konwencjonalnej reguły dotyczącej nazw plików i / align = "left" / )

Osobiście używam zarówno .h jak i .hpp w moich projektach C++. Nie stosuję się do powyższej konwencji, ponieważ:

• Języki używane przez każdą część projektów są wyraźnie udokumentowane. Brak możliwości mieszania C i c++ w tym samym module (katalogu). Każda biblioteka 3rdparty jest wymagana do przestrzegania tej reguły.
• zgodne specyfikacje językowe i dozwolone Dialekty języka używane przez projekty są również udokumentowane. (W rzeczywistości dokumentuję nawet źródło standardowych funkcji i poprawki błędów (na standard językowy) używane .) Jest to nieco ważniejsze niż odróżnianie używanych języków, ponieważ jest zbyt podatne na błędy i koszt testowania (np. kompatybilność kompilatora) może być znaczący (skomplikowany i czasochłonny), szczególnie w projekcie, który jest już w prawie czysty C++. Nazwy plików są zbyt słabe, by sobie z tym poradzić.
• nawet dla tego samego dialektu C++, mogą istnieć ważniejsze właściwości nadaje się do różnicy. Na przykład, zobacz konwencję poniżej.
• nazwy plików są zasadniczo fragmentami kruchych metadanych. Naruszenie konwencji nie jest tak łatwe do wykrycia. Aby być stabilnym w obsłudze treści, narzędzie powinno ostatecznie zależeć nie tylko od nazw. Różnica między rozszerzeniami to tylko podpowiedź. Nie należy również oczekiwać, że narzędzia korzystające z niego zachowują się cały czas tak samo, np. wykrywanie języka .h plików na github.com. (może być coś w komentarzach jak shebang aby te pliki źródłowe były lepszymi metadanymi, ale nawet nie są konwencjonalne jak nazwy plików, więc nie są one wiarygodne w ogóle.)

Zwykle używam .hpp Na nagłówkach C++ i nagłówki powinny być używane (utrzymywane) w sposób tylko w nagłówkach, np. jako biblioteki szablonów. Dla innych nagłówków w .h, albo istnieje odpowiedni plik .cpp jako implementacja, albo jest to nagłówek spoza C++. Ten ostatni jest trywialny, aby odróżnić zawartość nagłówek przez ludzi (lub przez narzędzia z jawnie osadzonymi metadanymi, w razie potrzeby).

Rozszerzenie pliku źródłowego może mieć znaczenie dla Twojego systemu kompilacji, na przykład możesz mieć regułę w pliku makefile dla plików .cpp lub .c, lub twój kompilator (np. Microsoft cl.exe) może skompilować plik jako C lub c++ w zależności od rozszerzenia.

Ponieważ musisz podać całą nazwę pliku do dyrektywy #include, rozszerzenie pliku nagłówkowego nie ma znaczenia. Jeśli chcesz, możesz dołączyć plik .c do innego pliku źródłowego, ponieważ jest to tylko tekstowy include. Twój kompilator może mieć opcję zrzutu wstępnie przetworzonego wyjścia, co wyjaśni to (Microsoft: {[5] } do preprocesu do pliku, {[6] } do preprocesu do stdout, /EP aby pominąć #line dyrektywy, /C aby zachować komentarze)

Możesz użyć .hpp dla plików, które są istotne tylko dla środowiska C++, tzn. używają funkcji, które nie będą kompilowane w C.

W "the C++ Programming Language, Third Edition by Bjarne Stroustrup", książka Nº1 must-read C++, używa *.H. zakładam więc, że najlepszą praktyką jest stosowanie *.h.

Jednak *.hpp też jest w porządku!

Żadne rozszerzenie nie ma żadnej korzyści, poza tym, że może mieć inne znaczenie dla Ciebie, kompilatora i / lub twoich narzędzi. header.h jest prawidłowym nagłówkiem. header.hpp jest prawidłowym nagłówkiem. header.hh jest prawidłowym nagłówkiem. header.hx jest prawidłowym nagłówkiem. h.header jest prawidłowym nagłówkiem. {[5] } jest prawidłowym nagłówkiem w zaprzeczeniu. {[6] } jest prawidłowym nagłówkiem. Tak długo, jak nazwa może być poprawnie przetworzona przez kompilator, a system plików ją obsługuje, jest to prawidłowy nagłówek, a jedyną zaletą jego rozszerzenia jest co się w nim czyta.

To powiedziawszy, możliwość dokładnego tworzenia założeń na podstawie rozszerzenia jest Bardzo użyteczna, więc byłoby mądrze użyć łatwo zrozumiałego zestawu reguł dla plików nagłówkowych. Osobiście wolę robić coś takiego:

1. jeśli istnieją już jakieś ustalone wytyczne, postępuj zgodnie z nimi, aby zapobiec zamieszaniu.
2. jeśli wszystkie pliki źródłowe w projekcie są dla tego samego języka, użyj .h. Nie ma dwuznaczność.
3. jeśli niektóre nagłówki są kompatybilne z wieloma językami, podczas gdy inne są kompatybilne tylko z jednym językiem, rozszerzenia są oparte na najbardziej restrykcyjnym języku, z którym jest kompatybilny nagłówek. Nagłówek kompatybilny z C, lub z C & C++, otrzymuje .h, podczas gdy nagłówek kompatybilny z C++, ale nie c otrzymuje .hpp lub .hh lub coś w tym rodzaju.

To oczywiście tylko jeden z} wielu sposobów radzenia sobie z rozszerzeniami i niekoniecznie zaufaj swojemu pierwszemu wrażeniu, nawet jeśli wszystko wydaje się proste. Na przykład, widziałem wzmiankę o używaniu {[7] } dla zwykłych nagłówków i .tpp dla nagłówków, które zawierają definicje tylko dla funkcji klasy szablonowej, z plikami .h, które definiują klasy szablonowe, w tym pliki .tpp, które definiują ich funkcje Członkowskie(zamiast nagłówka .h zawierającego bezpośrednio zarówno deklarację funkcji, jak i definicję). Dla innego przykładu, dobry wielu ludzi zawsze odzwierciedlają język nagłówka w jego rozszerzeniu, nawet jeśli nie ma szans na niejednoznaczność; dla nich {[7] } jest zawsze nagłówkiem C i .hpp (lub .hh, lub .hxx itd.) jest zawsze nagłówkiem C++. I jeszcze raz, niektórzy ludzie używają .h dla "nagłówka związanego z plikiem źródłowym" i .hpp dla "nagłówka ze wszystkimi funkcjami zdefiniowanymi w linii".

Biorąc to pod uwagę, główną zaletą byłoby konsekwentne nazywanie nagłówków w tym samym stylu i uczynienie tego stylu łatwo widocznym dla każdego, kto bada twoje nagłówki kod. W ten sposób każdy, kto zna twój zwykły styl kodowania, będzie w stanie określić, co masz na myśli z danym rozszerzeniem, pobieżnym spojrzeniem.