Zawsze używałem *.hpliku do definicji klas, ale po przeczytaniu kodu biblioteki doładowań zdałem sobie sprawę, że wszystkie z nich korzystają *.hpp. Zawsze miałem awersję do tego rozszerzenia plików, myślę, że głównie dlatego, że nie jestem do tego przyzwyczajony.

Jakie są wady i zalety korzystania z *.hppponad *.h?

Oto kilka powodów różnych nazw nagłówków C i C ++:

• Automatyczne formatowanie kodu, możesz mieć inne wytyczne dotyczące formatowania kodu C i C ++. Jeśli nagłówki są oddzielone rozszerzeniem, możesz ustawić edytor tak, aby automatycznie stosował odpowiednie formatowanie
• Nazywanie, byłem przy projektach, w których były biblioteki napisane w C, a następnie w C ++ zaimplementowano opakowania. Ponieważ nagłówki zwykle miały podobne nazwy, tj. Feature.h vs. Feature.hpp, łatwo je było odróżnić.
• Uwzględnij, być może twój projekt ma bardziej odpowiednie dostępne wersje napisane w C ++, ale używasz wersji C (patrz wyżej punkt). Jeśli nagłówki są nazwane po języku, w którym zostały zaimplementowane, możesz łatwo wykryć wszystkie nagłówki C i sprawdzić wersje C ++.

Pamiętaj, że C nie jest C ++ i mieszanie i dopasowywanie może być bardzo niebezpieczne, chyba że wiesz, co robisz. Odpowiednie nazewnictwo źródeł pomaga odróżnić języki.

Używam .hpp, ponieważ chcę, aby użytkownik rozróżniał, które nagłówki są nagłówkami C ++, a które nagłówki to C.

Może to być ważne, gdy twój projekt korzysta zarówno z modułów C, jak i C ++: Jak ktoś wcześniej mi wyjaśnił, powinieneś to zrobić bardzo ostrożnie, a zaczyna się od „umowy”, którą oferujesz poprzez rozszerzenie

.hpp: C ++ Nagłówki

(Lub .hxx lub .hh lub cokolwiek innego)

Ten nagłówek dotyczy tylko C ++.

Jeśli jesteś w module C, nawet nie próbuj go dołączać. Nie spodoba ci się, ponieważ nie podejmuje się żadnych wysiłków, aby uczynić go przyjaznym dla języka C (zbyt wiele by zostało utracone, jak przeciążenie funkcji, przestrzenie nazw itp.).

.h: nagłówki kompatybilne z C / C ++ lub czyste C.

Nagłówek ten może być zawarty zarówno przez źródło C, jak i źródło C ++, bezpośrednio lub pośrednio.

Może zawierać bezpośrednio, chroniony przez __cplusplusmakro:

• Co oznacza, że ​​z punktu widzenia C ++ kod kompatybilny z C zostanie zdefiniowany jako extern "C".
• Z punktu widzenia C cały kod C będzie wyraźnie widoczny, ale kod C ++ będzie ukryty (ponieważ nie skompiluje się 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ć zawarty pośrednio przez odpowiedni nagłówek .hpp załączający go do extern "C"deklaracji.

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 .hppnagłówek za rodzaj portmanteau .hi .cppplików ... nagłówek, który zawiera również szczegóły implementacji.

Zazwyczaj gdy widzę (i używam) .hppjako rozszerzenie, nie ma odpowiedniego .cpppliku. Jak powiedzieli inni, nie jest to twarda i szybka reguła, tak jak zwykle używam .hppplików.

Nie ma znaczenia, którego rozszerzenia używasz. Każda z nich jest OK.

Używam *.hdo C i *.hppC ++.

EDYCJA [Dodano sugestię Dana Nissenbauma]:

Według jednej konwencji 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 tworzeniu szablonu. Dlatego jeśli nie są zdefiniowane w plikach nagłówkowych, ich definicje nie zostaną rozwiązane w czasie łączenia z innymi jednostkami kompilacji. Jeśli twój projekt jest projektem opartym tylko na C ++, który intensywnie wykorzystuje szablony, ta konwencja będzie przydatna.

Niektóre biblioteki szablonów zgodne z tą konwencją udostępniają nagłówkom rozszerzenia .hpp wskazujące, że nie mają odpowiadających im plików .cpp.

inną konwencją jest użycie .h dla nagłówków C i .hpp dla C ++; dobrym przykładem może być biblioteka doładowań.

Cytat z Boost FAQ,

Rozszerzenia plików komunikują „typ” pliku, zarówno ludziom, jak i programom komputerowym. Rozszerzenie „.h” jest używane w plikach nagłówka C i dlatego przekazuje niewłaściwe informacje o plikach nagłówkowych C ++. Brak rozszerzenia nie komunikuje niczego i wymusza kontrolę zawartości pliku w celu ustalenia typu. Użycie „.hpp” jednoznacznie identyfikuje go jako plik nagłówkowy C ++ i działa dobrze w praktyce. (Rainer Deyke)

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

Powodem jest to, że używam emacsa jako mojego głównego edytora i wchodzi on automatycznie w tryb c po załadowaniu *.hpliku oraz w tryb c ++ po załadowaniu *.hpppliku.

Poza faktem, że nie widzę powodów, biorąc pod uwagę wybierając *.hsię *.hpplub vice versa.

Odpowiadam na to w celu przypomnienia o komentarzach do odpowiedzi „user1949346” na ten sam program operacyjny.

Tak więc wielu już odpowiedziało: tak czy inaczej jest w porządku. Następnie podkreśla własne wrażenia.

Wprowadzenie, tak jak w poprzednich wymienionych nazwanych komentarzach, moja opinia jest taka, że C++proponowane są rozszerzenia nagłówków, .hjeśli tak naprawdę nie ma żadnego powodu.

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

Ale teraz dążę do akceptowalnego powodu. DLACZEGO którykolwiek z tych sposobów jest w porządku, a zwłaszcza dlaczego nie jest on zależny od języka.

Więc zaczynamy.

C++Dokumentacja (ja faktycznie biorąc odwołanie od wersji N3690) określa, że nagłówek musi być zgodne 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 więc, jak możemy wyodrębnić z tej części, nazwa pliku nagłówka może być dowolną poprawną częścią kodu źródłowego. Z wyjątkiem zawierających '\n'znaki i w zależności od tego, czy ma zostać uwzględniony <>, nie może zawierać znaku >. Lub w inny sposób, jeśli jest dołączony przez ""-include, nie może zawierać ".

Innymi słowy: jeśli masz środowisko obsługujące nazwy plików prettyStupidIdea.>, takie jak:

#include "prettyStupidIdea.>"

byłoby ważne, ale:

#include <prettyStupidIdea.>>

byłby nieważny. Odwrotnie to samo.

I nawet

#include <<.<>

byłaby poprawną, możliwą do włączenia nazwą pliku nagłówka.

Nawet to byłoby zgodne C++, byłby to całkiem głupi pomysł, tho.

I dlatego też .hppjest ważny.

Ale to nie wynik decyzji komitetów opracowujących decyzje dotyczące języka!

Dyskusja na temat używania .hppjest tym samym, co robienie tego .cc, .mmlub o czymkolwiek innym, co czytam w innych postach na ten temat.

Muszę przyznać, że nie mam pojęcia, skąd .hpppochodzi ¹ , ale założę się, że wynalazca jakiegoś narzędzia do analizy, IDE lub czegoś innego zainteresowanego C++wpadł na ten pomysł, aby zoptymalizować niektóre wewnętrzne procesy lub po prostu wymyślić niektóre (prawdopodobnie nawet dla nich koniecznie ) nowe konwencje nazewnictwa.

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

I ilekroć ktoś decyduje się na to w ten sposób. Może dlatego, że lubi to najbardziej lub ponieważ niektóre aplikacje przepływu pracy tego wymagają, nigdy ² nie jest wymogiem języka. Więc ktokolwiek powie „pp jest dlatego, że jest używany z C ++”, po prostu się myli w odniesieniu do definicji języków.

C ++ dopuszcza wszystko, co jest zgodne z poprzednim akapitem. A jeśli jest coś, co komitet zaproponował użyć, to używa, .hponieważ jest to rozszerzenie pozwane we wszystkich przykładach dokumentu ISO.

Wniosek:

Tak długo, jak nie widzisz / nie odczuwasz potrzeby używania .hover .hppi vice versa, nie powinieneś się tym przejmować. Ponieważ oba będą stanowić prawidłową nazwę nagłówka o tej samej jakości w stosunku do standardu. A zatem wszystko, co WYMAGA korzystania .hlub .hppstanowi dodatkowe ograniczenie 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 żadnym dodatkowym ograniczeniu językowym, jest to jedyna poprawna i akceptowalna odpowiedź na pytanie

„ * .h lub * .hpp dla definicji klas ” to:

Oba są jednakowo poprawne i obowiązują, o ile nie występują żadne ograniczenia zewnętrzne.

¹ _{Z tego, co wiem, najwyraźniej to właśnie ramy doładowań wymyśliły to .hpprozszerzenie.}

² _{Oczywiście nie mogę powiedzieć, co przyniosą niektóre przyszłe wersje!}

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.

C ++ („C Plus Plus”) ma sens jako .cpp

Pliki nagłówkowe z rozszerzeniem .hpp nie mają tego samego logicznego przepływu.

Możesz nazywać swoje załączniki, jak chcesz.

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

Sugeruję, że jeśli pracujesz z C, aby użyć, .ha kiedy z C ++, aby użyć .hpp.

To w końcu tylko konwencja.

Codegear C ++ Builder używa .hpp do plików nagłówkowych generowanych automatycznie z plików źródłowych Delphi, a .h do własnych plików nagłówkowych.

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

W jednym z moich zadań na początku lat 90. używaliśmy .cc i .hh odpowiednio dla plików źródłowych i nagłówkowych. Nadal wolę to niż wszystkie alternatywy, prawdopodobnie dlatego, że najłatwiej jest pisać.

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

SF.1: Użyj sufiksu .cpp dla plików kodu i .h dla plików interfejsu, jeśli Twój projekt Y nie przestrzega innej konwencji Przyczyna

To długoletnia konwencja. 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 powszechny wzorzec użycia: Nagłówki są częściej współużytkowane z C w celu kompilacji zarówno w C ++, jak i C, który zwykle używa .h, i łatwiej jest nazwać wszystkie nagłówki .h zamiast mieć różne rozszerzenia tylko dla tych nagłówków, które są zamierzone do współdzielenia z C. Z drugiej strony pliki implementacyjne są rzadko udostępniane w C i dlatego zwykle należy je odróżnić od plików .c, więc zwykle najlepiej nazwać wszystkie pliki implementacyjne C ++ czymś innym (np. .cpp).

Konkretne nazwy .h i .cpp nie są wymagane (tylko zalecane jako domyślne), a inne nazwy są w powszechnym użyciu. Przykładami są .hh, .C i .cxx. Używaj takich nazw w sposób równoważny. W tym dokumencie nazywamy .h i .cpp> skrótem plików nagłówkowych i implementacyjnych, nawet jeśli rzeczywiste rozszerzenie może być inne.

Twoje IDE (jeśli go używasz) może mieć mocne opinie na temat wystarczających.

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

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

Większość bibliotek, które tworzę, są oparte na szablonach i dlatego muszą być tylko nagłówkami, ale podczas pisania aplikacji zwykle oddzielam deklarację od implementacji i kończę na plikach .h i .cpp

Na szczęście jest to proste.

Powinieneś użyć rozszerzenia .hpp, jeśli pracujesz z C ++ i powinieneś użyć .h do C lub mieszania C i C ++.

Używam .h, ponieważ tego właśnie używa Microsoft i tego, co tworzy ich generator kodów. Nie musisz iść pod prąd.

W „The C ++ Programming Language, Third Edition Bjarne Stroustrup”, najważniejszej książce C ++, którą należy przeczytać, używa * .h. Zakładam więc, że najlepszą praktyką jest użycie * .h.

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

Narzędziom i ludziom łatwo jest coś odróżnić . Otóż ​​to.

W konwencjonalnym użyciu (przez boost, itp.), W .hppszczególności są nagłówki C ++. Z drugiej strony .hdotyczy nagłówków innych niż C ++ (głównie C). Precyzyjne wykrywanie języka treści jest na ogół trudne, ponieważ istnieje wiele nietrywialnych przypadków, więc różnica ta często sprawia, że ​​gotowe do użycia narzędzie jest łatwe do napisania. Po przyjęciu konwencji dla ludzi jest również łatwy do zapamiętania i łatwy w użyciu.

Zaznaczam jednak, że sama konwencja nie zawsze działa zgodnie z oczekiwaniami.

• Nie jest to wymuszone 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ć (mieszać), może to być kłopotliwe.
• .hppsam nie jest jedynym wyborem. Dlaczego nie .hhczy .hxx? (W każdym razie zazwyczaj potrzebujesz co najmniej jednej konwencjonalnej reguły dotyczącej nazw plików i ścieżek).

Osobiście korzystam zarówno z moich projektów C ++, jak .hi .hppz nich. Nie przestrzegam powyższej konwencji, ponieważ:

• Języki używane w każdej części projektów są wyraźnie udokumentowane. Nie ma szans na mieszanie C i C ++ w tym samym module (katalogu). Każda biblioteka strony trzeciej musi spełniać tę regułę.
• Dokumentowane są również specyfikacje języka zgodne i dozwolone dialekty językowe stosowane w projektach. (W rzeczywistości dokumentuję nawet źródło używanych standardowych funkcji i poprawek błędów (w standardzie językowym) .) Jest to nieco ważniejsze niż rozróżnianie używanych języków, ponieważ jest zbyt podatny na błędy i koszt testu (np. kompatybilność z kompilatorem) może być znacząca (skomplikowana i czasochłonna), szczególnie w projekcie, który jest już w prawie czystym języku C ++. Nazwy plików są zbyt słabe, aby sobie z tym poradzić.
• Nawet dla tego samego dialektu C ++ mogą istnieć ważniejsze właściwości odpowiednie do różnicy. Na przykład zobacz konwencję poniżej.
• Nazwy plików są zasadniczo fragmentami delikatnych metadanych. Naruszenie konwencji nie jest tak łatwe do wykrycia. Aby zachować stabilność w zakresie treści, narzędzie powinno ostatecznie nie tylko zależeć od nazw. Różnica między rozszerzeniami jest tylko wskazówką. Narzędzia, które go używają, również nie powinny działać tak samo przez cały czas, np .h. Wykrywanie języka plików na github.com. (W komentarzach może być coś takiego jak shebang, aby te pliki źródłowe były lepszymi metadanymi, ale nawet nie są one konwencjonalne jak nazwy plików, więc ogólnie nie są wiarygodne).

Zwykle używam .hppnagłówków C ++ i nagłówki powinny być używane (utrzymywane) tylko w nagłówkach , np. Jako biblioteki szablonów. W przypadku innych nagłówków w pliku .histnieje albo odpowiedni .cppplik jako implementacja, albo nagłówek inny niż C ++. To ostatnie jest trywialne do odróżnienia zawartości nagłówka przez ludzi (lub przez narzędzia z jawnie osadzonymi metadanymi, jeśli to konieczne).

Rozszerzenie pliku źródłowego może mieć znaczenie dla twojego systemu kompilacji, na przykład możesz mieć regułę w swoim makefile dla plików .cpplub .cplików, 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 #includedyrektywy, rozszerzenie pliku nagłówka nie ma znaczenia. Jeśli chcesz, możesz dołączyć .cplik do innego pliku źródłowego, ponieważ jest to tylko tekst. Twój kompilator może mieć opcję zrzucenia wstępnie przetworzonych danych wyjściowych, co to wyjaśni (Microsoft: /Pwstępne przetwarzanie do pliku, /Ewstępne przetwarzanie stdout, /EPpomijanie #linedyrektyw, /Czachowanie komentarzy)

Możesz użyć .hpppliku, który dotyczy tylko środowiska C ++, tzn. Używają funkcji, które nie będą się kompilować w C.

Żadne konkretne rozszerzenie nie ma żadnej korzyści, poza tym, że może mieć inne znaczenie dla Ciebie, kompilatora i / lub twoich narzędzi. header.hjest prawidłowym nagłówkiem. header.hppjest prawidłowym nagłówkiem. header.hhjest prawidłowym nagłówkiem. header.hxjest prawidłowym nagłówkiem. h.headerjest prawidłowym nagłówkiem. this.is.not.a.valid.headerjest prawidłowym nagłówkiem odmowy. ihjkflajfajfklafjest prawidłowym nagłówkiem. Tak długo, jak nazwa może zostać poprawnie przeanalizowana przez kompilator, a system plików ją obsługuje, jest to prawidłowy nagłówek, a jedyną zaletą rozszerzenia jest to, co się w nim odczytuje.

To powiedziawszy, możliwość dokładnego przyjmowania założeń na podstawie rozszerzenia jest bardzo przydatna, dlatego rozsądnie byłoby zastosować łatwo zrozumiały zestaw reguł dla plików nagłówkowych. Osobiście wolę zrobić coś takiego:

1. Jeśli istnieją już ustalone wytyczne, postępuj zgodnie z nimi, aby uniknąć zamieszania.
2. Jeśli wszystkie pliki źródłowe w projekcie są w tym samym języku, użyj .h. Nie ma dwuznaczności.
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 nagłówek jest kompatybilny. Główka kompatybilny z C, lub z obu C & C ++, dostaje .h, natomiast nagłówek kompatybilny z C ++, ale nie dostaje C .hpplub .hhczy coś w tym rodzaju.

Jest to oczywiście jeden z wielu sposobów obsługi rozszerzeń i niekoniecznie możesz zaufać swojemu pierwszemu wrażeniu, nawet jeśli wszystko wydaje się proste. Na przykład, widziałem wzmiankę o używaniu .hdla normalnych nagłówków i .tppdla nagłówków, które zawierają tylko definicje funkcji składowych klasy w szablonie, z .hplikami, które definiują klasy szablonowe, w tym .tpppliki, które definiują ich funkcje składowe (zamiast .hnagłówka zawierającego bezpośrednio oba deklaracja funkcji i definicja). Na przykład, wiele osób zawsze odzwierciedla język nagłówka w jego rozszerzeniu, nawet jeśli nie ma szans na dwuznaczność; dla nich .hzawsze jest nagłówek C i .hpp(lub .hh, lub.hxxitp.) jest zawsze nagłówkiem C ++. I znowu, niektórzy ludzie używają .h„nagłówka skojarzonego z plikiem źródłowym” i .hpp„nagłówka ze wszystkimi funkcjami zdefiniowanymi inline”.

Biorąc to pod uwagę, główną zaletą byłoby konsekwentne nazywanie nagłówków tym samym stylem i uczynienie tego stylu widocznym dla każdego, kto bada twój 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, tylko pobieżnym spojrzeniem.