*.hSınıf tanımlarım için her zaman bir dosya kullandım , ancak bazı destek kitaplığı kodunu okuduktan sonra hepsinin kullandığını fark ettim *.hpp. Her zaman bu dosya uzantısına karşı bir isteksizlik yaşadım, bence esas olarak alışkın değilim.

*.hppAşırı kullanmanın avantajları ve dezavantajları *.hnelerdir?

C ve C ++ başlıklarının farklı adlandırılmasının birkaç nedeni:

• Otomatik kod biçimlendirme, C ve C ++ kodunu biçimlendirmek için farklı kurallarınız olabilir. Başlıklar uzantıyla ayrılırsa, düzenleyicinizi uygun biçimlendirmeyi otomatik olarak uygulayacak şekilde ayarlayabilirsiniz
• Adlandırma, C ile yazılmış kütüphanelerin olduğu ve daha sonra C ++ 'da paketlerin uygulandığı projelerde bulundum. Başlıklar genellikle benzer isimlere sahip oldukları için, örneğin Feature.h ve Feature.hpp, birbirinden ayırt etmek kolaydı.
• Ek olarak, projenizde C ++ ile yazılmış daha uygun sürümler olabilir, ancak C sürümünü kullanıyorsunuz (yukarıdaki noktaya bakın). Başlıklar, uygulandıkları dilden sonra adlandırılırsa, tüm C başlıklarını kolayca tespit edebilir ve C ++ sürümlerini kontrol edebilirsiniz.

Unutmayın, C C ++ değildir ve ne yaptığınızı bilmiyorsanız karıştırmak ve eşleştirmek çok tehlikeli olabilir. Kaynaklarınızı uygun şekilde adlandırmak, dilleri birbirinden ayırmanıza yardımcı olur.

.Hpp kullanıyorum çünkü kullanıcının hangi başlıkların C ++ başlıkları olduğunu ve hangi başlıkların C başlıkları olduğunu ayırt etmesini istiyorum.

Projeniz hem C hem de C ++ modüllerini kullanırken bu önemli olabilir: Benden önce açıkladığı gibi, bunu çok dikkatli bir şekilde yapmalısınız ve bu, uzantı aracılığıyla sunduğunuz "sözleşme" ile başlar.

.hpp: C ++ Üstbilgileri

(Veya .hxx veya .hh veya her neyse)

Bu başlık yalnızca C ++ içindir.

Bir C modülündeyseniz, eklemeyi bile denemeyin. Bunu sevmeyeceksiniz, çünkü C dostu yapmak için hiçbir çaba gösterilmez (işlev aşırı yüklenmesi, ad alanları vb. Gibi çok fazla şey kaybedilir).

.h: C / C ++ uyumlu veya saf C Başlıkları

Bu başlık, doğrudan veya dolaylı olarak hem bir C kaynağı hem de bir C ++ kaynağı tarafından eklenebilir.

__cplusplusMakro tarafından korunarak doğrudan dahil edilebilir :

• Bu, C ++ bakış açısından, C uyumlu kodun tanımlanacağı anlamına gelir extern "C".
• Bir C bakış açısından, tüm C kodu açıkça görülebilir, ancak C ++ kodu gizlenecektir (çünkü bir C derleyicisinde derlenmeyecektir).

Örneğin:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

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

#endif // MY_HEADER_H

Veya dolaylı olarak, extern "C"bildirimle çevreleyen ilgili .hpp üstbilgisi tarafından dahil edilebilir .

Örneğin:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

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

#endif // MY_HEADER_HPP

ve:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

Her zaman .hppüstbilgiyi bir tür portmanteau .hve .cppdosya olarak gördüm ... uygulama ayrıntılarını da içeren bir üstbilgi.

Genellikle .hppbir uzantı olarak gördüğümde (ve kullandığımda) , karşılık gelen bir .cppdosya yoktur . Diğerlerinin söylediği gibi, bu zor ve hızlı bir kural değil, sadece .hppdosyaları kullanma eğilimim .

Hangi uzantıyı kullandığınız önemli değildir. İkisinden biri iyi.

Kullandığım *.hC ve *.hppC ++ için.

EDIT [Dan Nissenbaum'dan öneri eklendi]:

Bir kuralla, prototipler başlığın kendisinde tanımlandığında .hpp dosyaları kullanılır. Derleyiciler her şablon için sadece şablon örneklemesinde kod oluşturduğundan, üstbilgilerdeki bu tür tanımlar şablonlar için kullanışlıdır. Bu nedenle, başlık dosyalarında tanımlanmamışlarsa, tanımları bağlantı zamanında diğer derleme birimlerinden çözümlenmeyecektir. Projeniz, şablonları yoğun şekilde kullanan yalnızca C ++ projesiyse bu kural yararlı olacaktır.

Bu kurala uyan belirli şablon kitaplıkları, başlıklara karşılık gelen .cpp dosyalarının olmadığını belirtmek için .hpp uzantıları sağlar.

diğer bir kural ise C başlıkları için .h ve C ++ için .hpp kullanmaktır; Buna iyi bir örnek boost kütüphanesi olabilir.

Boost SSS'den alıntı,

Dosya uzantıları, dosyanın "türünü" hem insanlara hem de bilgisayar programlarına iletir. '.H' uzantısı C başlık dosyaları için kullanılır ve bu nedenle C ++ başlık dosyaları hakkında yanlış bir şey bildirir. Uzantı kullanmamak hiçbir şey iletmez ve dosya türünü denetlemeye zorlanır. '.Hpp' kullanmak onu açıkça C ++ başlık dosyası olarak tanımlar ve gerçek uygulamada iyi çalışır. (Rainer Deyke)

Son zamanlarda *.hppc ++ başlıkları için kullanmaya başladım .

Bunun nedeni, birincil düzenleyicim olarak emacs kullanmam ve bir *.hdosya yüklediğinizde otomatik olarak c-moduna ve bir dosya yüklediğinizde c ++ moduna girmesidir *.hpp.

Dışında aslında ben seçtiğiniz için iyi nedenler gördükleri *.hüzerinde*.hpp veya tersi.

Bu OP için "user1949346" yanıtı hakkındaki yorum (ları )mı belirtmek için bunu bir hatırlatma olarak yanıtlıyorum.

Pek çok kişi zaten cevap verdi: her iki şekilde de iyi. Ardından kendi izlenimlerini vurgular.

Giriş, daha önce belirtilen adlandırılan yorumlarda olduğu gibi, bence C++başlık uzantıları .haslında buna karşı bir neden yoksa önerilmektedir .

ISO / IEC belgeleri başlık dosyalarının bu gösterimini kullandığından .hppve dil belgelerindeC++ .

Ama şimdi neden her iki durumda da uygun olduğunu ve özellikle neden kendi diline tabi olmadığını onaylamak için bir amaç hedefliyorum.

İşte başlıyoruz.

C++Dokümantasyon (Aslında sürümü N3690 gelen referans alıyorum) bir başlık aşağıdaki sözdizimine uyması sahip olduğunu tanımlar:

2.9 Başlık adları

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 "

Bu nedenle, bu bölümden ayıklayabileceğimiz gibi, başlık dosya adı da kaynak kodunda geçerli olan herhangi bir şey olabilir. '\n'Karakter içermesi dışında ve dahil edilip <>edilmeyeceğine bağlı olarak a içermesine izin verilmez >. Ya da ""-include tarafından dahil edilmişse , a içermesine izin verilmez ".

Başka bir deyişle: dosya adlarını destekleyen bir ortamınız varsa prettyStupidIdea.>, aşağıdakileri ekleyin:

#include "prettyStupidIdea.>"

geçerli olur, ancak:

#include <prettyStupidIdea.>>

geçersiz olur. Tam tersi.

Ve hatta

#include <<.<>

geçerli bir eklenebilir başlık dosya adı olur.

Bu bile uygun olsa bile C++, oldukça aptalca bir fikir olurdu, tho.

İşte bu yüzden .hppde geçerlidir.

Ancak bu, dil için kararlar veren komitelerin bir sonucu değildir!

Kullanımına dair tartışırken Yani .hppyaklaşık yapıyor aynıdır .cc, .mmya da hiç başka ne bu konuda diğer mesajlar okundu.

İtiraf etmeliyim ki ^1'den.hpp gelen hiçbir fikrim yok , ama bazı içsel süreçleri optimize etmek veya sadece bazılarını icat etmek için bu fikre gelen bazı ayrıştırma aracı, IDE veya başka bir şeyin mucidine bahse girerim. ) yeni adlandırma kuralları.C++

Ama dilin bir parçası değil.

Ve kişi bu şekilde kullanmaya karar verdiğinde. O iş akışının bazı uygulamalar bunu gerektirir çünkü ya, asla en sevdiği olmasından kaynaklanabilir ² dilinin bir gerekliliktir. Yani "pp, C ++ ile kullanıldığı için" diyen herkes, dil tanımı açısından yanlıştır.

C ++, önceki paragrafa saygılı herhangi bir şeye izin verir. Komitenin kullanmasını önerdiği bir şey varsa .h, ISO belgesinin tüm örneklerinde belirtilen uzantı olduğu için kullanıyor .

Sonuç:

.hAşırı .hppveya tam tersini kullanma ihtiyacı görmediğiniz / hissetmediğiniz sürece , rahatsız etmemelisiniz. Çünkü her ikisi de standarda göre aynı kalitede geçerli bir başlık adı oluşturur. Ve bu nedenle her şey GEREKTİRİR Kullanmak .hya .hppda diğer ek kısıtlamalara aykırı olabilir standardın ek bir kısıtlama değildir birbirleriyle uyumludur. Ancak OP herhangi bir ek dil kısıtlamasından bahsetmediğinden, bu sorunun tek doğru ve onaylanabilir cevabıdır

" Sınıf tanımlarınız için * .h veya * .hpp ":

Hiçbir dış sınırlama olmadığı sürece her ikisi de eşit derecede doğrudur ve uygulanabilir.

¹ _{Bildiğim kadarıyla, görünüşe göre, bu .hppuzantı ile ortaya çıkan destek çerçevesi .}

² _{Tabii ki gelecekteki bazı sürümlerin beraberinde ne getireceğini söyleyemem!}

Ben hem editörler hem de diğer programcılar için bir C başlık dosyası yerine bir C ++ başlık olduğunu açıklamak için .hpp tercih ederim.

C ++ ("C Plus Plus") .cpp olarak anlamlıdır

Bir .hpp uzantısına sahip başlık dosyalarına sahip olmak aynı mantıksal akışa sahip değildir.

İçeriğinizi istediğiniz gibi arayabilirsiniz.

Sadece bu tam adı #include.

Ben kullanmak için C ve kullanmak .hiçin C ++ ile çalışıyorsanız öneririz .hpp.

Sonunda sadece bir kongre.

Codegear C ++ Builder, Delphi kaynak dosyalarından otomatik olarak oluşturulan başlık dosyaları için .hpp ve "kendi" başlık dosyalarınız için .hpp kullanır.

Yani, bir C ++ başlık dosyası yazarken her zaman .h kullanıyorum.

90'lı yılların başındaki işlerimden birinde, kaynak ve başlık dosyaları için sırasıyla .cc ve .hh kullandık. Hala tüm alternatiflere tercih ediyorum, muhtemelen yazmanın en kolay yolu çünkü.

: Bjarne Stroustrup ve Herb Sutter bulunan kendi C ++ Çekirdek yönergelerinde bu soruya bir açıklama var https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source da son değişiklikler refering standart uzantıda (C ++ 11, C ++ 14 vb.)

SF.1: Y projeniz başka bir kural izlemiyorsa, kod dosyaları için bir .cpp soneki ve arabirim dosyaları için .h kullanın

Uzun zamandır devam eden bir toplantı. Ancak tutarlılık daha önemlidir, bu nedenle projeniz başka bir şey kullanıyorsa, bunu izleyin. Not

Bu kural yaygın bir kullanım örüntüsünü yansıtır: Üstbilgiler genellikle genellikle .h kullanan C ++ ve C olarak derlemek için C ile paylaşılır ve yalnızca amaçlanan bu başlıklar için farklı uzantılara sahip olmak yerine tüm başlıkları .h olarak adlandırmak daha kolaydır Öte yandan, uygulama dosyaları C ile nadiren paylaşılır ve bu nedenle genellikle .c dosyalarından ayırt edilmelidir, bu nedenle normalde tüm C ++ uygulama dosyalarını başka bir şey (.cpp gibi) olarak adlandırmak en iyisidir.

Belirli adlar .h ve .cpp gerekli değildir (sadece varsayılan olarak önerilir) ve diğer adlar yaygın olarak kullanılmaktadır. Örnek olarak .hh, .C ve .cxx verilebilir. Bu adları aynı şekilde kullanın. Bu belgede, gerçek uzantı farklı olsa da, başlık ve uygulama dosyaları için bir kısayol olarak .h ve .cpp> ifadelerini kullanıyoruz.

IDE'niz (eğer birini kullanırsanız) yeterlilikler hakkında güçlü görüşlere sahip olabilir.

Bu konvansiyonun büyük bir hayranı değilim çünkü boost gibi popüler bir kütüphane kullanıyorsanız, tutarlılığınız zaten kırılmış ve .hpp'yi daha iyi kullanmalısınız.

Burada daha önce de belirtildiği gibi, şablon sınıfları / işlevleri kullanan yalnızca başlık kitaplıkları için .hpp kullanmayı tercih ederim. .Cpp kaynak dosyaları veya paylaşılan veya statik kitaplıklar ile birlikte başlık dosyaları için .h kullanmayı tercih ederim.

Geliştirdiğim kitaplıkların çoğu şablon tabanlıdır ve bu nedenle yalnızca başlık olmalıdır, ancak uygulamaları yazarken bildirimi uygulamadan ayırmaya ve .h ve .cpp dosyalarıyla sonuçlanmaya meyilliyim.

Neyse ki, basit.

C ++ ile çalışıyorsanız .hpp uzantısını ve C için C veya C ve C ++ 'ı karıştırmak için .h kullanmanız gerekir.

.H kullanıyorum, çünkü Microsoft bunu kullanıyor ve kod üretecini yaratıyor. Tahıllara karşı gitmeye gerek yok.

"Cjar Programlama Dili, Bjarne Stroustrup'un Üçüncü Sürümü" nde, nº1 C ++ kitabını okumalıdır, * .h kullanır. Bu yüzden en iyi uygulamanın * .h kullanmak olduğunu varsayalım.

Ancak, * .hpp de iyidir!

Aletler ve insanlar için bir şeyi ayırt etmek kolaydır . Bu kadar.

Geleneksel kullanımda (takviye vb. İle), .hppözellikle C ++ başlıklarıdır. Öte yandan, .hsadece C ++ olmayan başlıklar içindir (çoğunlukla C). Önemsiz olan birçok durum olduğundan, içeriğin dilini kesin olarak tespit etmek genellikle zordur, bu nedenle bu fark genellikle kullanıma hazır bir aracın yazılmasını kolaylaştırır. İnsanlar için, bir kez konvansiyonu alırsanız, hatırlanması ve kullanımı da kolaydır.

Ancak, sözleşmenin beklendiği gibi her zaman işe yaramadığına dikkat çekerim.

• Ne C ne de C ++ dillerinin belirtilmesi ile zorlanmaz . Sözleşmeyi takip etmeyen birçok proje var. Onları birleştirmeniz (karıştırmanız) gerektiğinde, sorun yaratabilir.
• .hpptek seçenek değildir. Neden olmasın .hhya da .hxx? (Yine de, dosya adları ve yollar hakkında genellikle en az bir geleneksel kurala ihtiyacınız vardır.)

Ben şahsen ikisini de kullanmak .hve .hppbenim C ++ projelerde. Yukarıdaki sözleşmeyi takip etmiyorum çünkü:

• Projelerin her bir parçası tarafından kullanılan diller açıkça belgelenmiştir. Aynı modülde (dizin) C ve C ++ 'ı karıştırma şansı yok. Her üçüncü taraf kütüphanesinin bu kurala uyması gerekir.
• Projeler tarafından kullanılan uygun dil özellikleri ve izin verilen dil lehçeleri de belgelenmiştir. (Aslında, belgeyi bile kullanılan standart özelliklerin ve hata düzeltmesinin (dil standardında) kaynağını .) Bu, çok hataya eğilimli olduğu ve testin maliyeti olduğu için kullanılan dilleri ayırt etmekten biraz daha önemlidir (ör. derleyici uyumluluğu), özellikle neredeyse saf C ++ 'da olan bir projede önemli (karmaşık ve zaman alıcı) olabilir . Dosya adları bunun üstesinden gelemeyecek kadar zayıf.
• Aynı C ++ lehçesi için bile, farka uygun daha önemli özellikler olabilir. Örneğin, aşağıdaki kurala bakın.
• Dosya adları esasen kırılgan meta verilerin parçalarıdır. Sözleşmenin ihlalini tespit etmek o kadar kolay değildir. İçeriği ele almak için kararlı olmak için, bir araç eninde sonunda sadece isimlere bağlı olmamalıdır. Uzantılar arasındaki fark sadece bir ipucudur. Bunu kullanan araçların her zaman aynı davranması beklenmemelidir, örneğin .hgithub.com'daki dosyaların dil algılaması . (Yorumlarda shebang gibi bir şey olabilir daha iyi meta olmak için bu kaynak dosyaları için, ama o kadar da hatta genel olarak güvenilir değildir Dosya adlarında gibi değil geleneksel budur.)

Genellikle .hppC ++ üstbilgilerinde kullanırım ve üstbilgiler yalnızca başlık olarak, örneğin şablon kitaplıkları olarak kullanılmalıdır (korunmalıdır) . İçindeki diğer üstbilgiler için .h, .cppuygulama olarak karşılık gelen bir dosya vardır veya C ++ olmayan bir üstbilgidir. İkincisi, üstbilginin içeriğini insanlar (veya gerekirse açık gömülü meta verilere sahip araçlar) ile ayırt etmek önemsizdir.

Kaynak dosyanın uzantısının derleme sisteminiz için bir anlamı olabilir, örneğin, makefile .cppveya .cfiles için bir kuralınız olabilir veya derleyiciniz (örneğin Microsoft cl.exe), uzantıya bağlı olarak dosyayı C veya C ++ olarak derleyebilir.

#includeDirektifin tüm dosya adını vermeniz gerektiğinden , başlık dosya uzantısı önemsizdir. İsterseniz .cbaşka bir kaynak dosyaya dosya ekleyebilirsiniz , çünkü bu yalnızca metinsel bir içerme işlemidir. Derleyicinizin bunu önceden netleştirecek olan önceden işlenmiş çıktıyı dökümü seçeneği olabilir (Microsoft: /Pdosyaya /Eönişleme yapmak stdout, önişleme yapmak , yönergeleri /EPatlamak #line, /Cyorumları tutmak için)

.hppYalnızca C ++ ortamıyla ilgili dosyalar için kullanmayı tercih edebilirsiniz , yani C'de derlenmeyen özellikler kullanırlar.

Herhangi bir uzantının avantajı yoktur, bunun dışında sizin, derleyicinin ve / veya araçlarınızın sizin için farklı bir anlamı olabilir. header.hgeçerli bir başlık. header.hppgeçerli bir başlık. header.hhgeçerli bir başlık. header.hxgeçerli bir başlık. h.headergeçerli bir başlık. this.is.not.a.valid.headerreddedilen geçerli bir başlıktır. ihjkflajfajfklafgeçerli bir başlık. Ad derleyici tarafından düzgün bir şekilde ayrıştırılabildiği ve dosya sistemi desteklediği sürece, geçerli bir başlıktır ve uzantısının tek avantajı, kişinin okuduğu şeydir.

Bununla birlikte, uzantıya dayalı olarak varsayımları doğru bir şekilde yapabilmek çok yararlıdır, bu nedenle başlık dosyalarınız için kolayca anlaşılabilir bir kurallar kümesi kullanmak akıllıca olacaktır. Şahsen ben böyle bir şey yapmayı tercih ederim:

1. Önceden belirlenmiş yönergeler varsa, karışıklığı önlemek için bu yönergeleri izleyin.
2. Projedeki tüm kaynak dosyalar aynı dil içinse, .h . Belirsizlik yok.
3. Bazı üstbilgiler birden çok dille uyumluyken, diğerleri yalnızca tek bir dille uyumluysa, uzantılar bir üstbilginin uyumlu olduğu en kısıtlayıcı dili temel alır. C ++ ile uyumlu ya da C & C ++ .hile uyumlu bir başlık alırken, C ++ ile uyumlu ancak C ile uyumlu olmayan bir başlık .hppya .hhda bu tür bir şey alır .

Bu, elbette, uzantıları ele almanın birçok yolundan biridir ve işler doğrudan görünse bile ilk izleniminize güvenemezsiniz. Örneğin, .hnormal üstbilgiler .tppiçin ve yalnızca şablonlanmış sınıf üyesi işlevlerinin tanımlarını içeren üstbilgiler için,.h dahil templated sınıfları tanımlar dosyaların .tppyerine (bunların üye işlevlerini tanımlayan dosyalar .hdoğrudan hem içeren başlığındaki işlev beyanı ve tanımı). Başka bir örnek olarak, çok sayıda insan belirsizlik şansı olmasa bile başlığın dilini uzantısında her zaman yansıtır; onlara .hher zaman bir C başlığı ve.hpp (veya.hh , veya.hxxvb.) her zaman bir C ++ üst bilgisidir. Ve yine, bazı insanlar .h"bir kaynak dosyayla ilişkili üstbilgi" ve .hpp"satır içi tanımlanmış tüm işlevlere sahip üstbilgi" için kullanırlar.

Bunu göz önünde bulundurarak, ana avantaj, başlıklarınızı sürekli olarak aynı stilde adlandırmak ve bu stili kodunuzu inceleyen herkes için kolayca görünür hale getirmek olacaktır. Bu şekilde, her zamanki kodlama stilinize aşina olan herkes, herhangi bir uzantıyla ne demek istediğini sadece üstünkörü bir bakışla belirleyebilecektir.