Başlık dosyasında ne olmalı ve ne olmamalıdır? [kapalı]

Hangi şeyler kesinlikle bir başlık dosyasına dahil edilmemelidir?

Örneğin, çok fazla sabiti olan belgelenmiş bir endüstri standardı formatı ile çalışıyorsam, bunları bir başlık dosyasında tanımlamak iyi bir uygulama mıdır (eğer bu format için bir çözümleyici yazıyorsam)?

Başlık dosyasına hangi fonksiyonlar girmelidir?
Hangi fonksiyonlar olmamalı?

Başlıklara neler yazılmalı:

• #includeÜstbilgi bazı kaynak dosyalara dahil edildiğinde üstbilgiyi derlenebilir hale getirmek için gereken en küçük yönergeler kümesi .
• Önişlemci, paylaşılması gereken ve yalnızca önişlemci ile yapılabilecek şeylerin tanımlarını tanımlar. C de olsa, önişlemci sembolleri en azda tutulmalıdır.
• Yapının tanımlarını, fonksiyon prototiplerini ve başlığın gövdesindeki global değişken bildirimlerini derlenebilir hale getirmek için gereken yapıların ileri bildirimleri.
• Birden fazla kaynak dosya arasında paylaşılan veri yapılarının ve numaralandırmaların tanımları.
• Tanımları bağlayıcıya görünür olacak işlevler ve değişkenler için bildirimler.
• Satır içi işlev tanımları, ancak burada dikkat edin.

Bir başlığa ait olmayan ne:

• Bedava #includedirektifler. Bu bedava olanlar, yeniden derlenmesi gerekmeyen şeylerin yeniden derlenmesine neden oluyor ve bazen sistemin derleyememesini sağlayabilir. Yapma #includebaşlığı kendisi o diğer başlık dosyasını ihtiyacı yoksa bir başlık bir dosyayı.
• Amacı bazı mekanizmalar, önişleyiciler dışındaki herhangi bir mekanizma ile gerçekleştirilebilecek önişlemci sembolleri.
• Çok ve çok sayıda yapı tanımı. Bunları ayrı başlıklara ayırın.
• Ek gerektiren #include, değişebilen veya çok büyük olan işlevlerin satır içi tanımları . Bu satır içi işlevler, herhangi bir fan çıkışı durumunda çok az olmalıdır ve eğer fanları varsa, başlıkta tanımlanan öğelere yerelleştirilmelidir.

Minimum ifade kümesini ne oluşturur #include?

Bu önemsiz bir soru olarak ortaya çıkıyor. Bir TL; DR tanımı: Bir başlık dosyası, doğrudan kullanılan ya da söz konusu başlık dosyasında kullanılan işlevlerin her birini doğrudan bildiren, ancak başka bir şey içermemesi gereken başlık dosyalarının her birini doğrudan tanımlayan başlık dosyalarını içermelidir. Bir işaretçi veya C ++ referans türü doğrudan kullanım olarak nitelendirilmez; ileri referanslar tercih edilir.

Boş bir #includedirektif için bir yer var ve bu otomatik bir testte. Bir yazılım paketindeki her başlık dosyası için, aşağıdakileri otomatik olarak oluşturup derlerim:

#include "path/to/random/header_under_test"
int main () { return 0; }

Derleme temiz olmalıdır (örn. Herhangi bir uyarı veya hata olmamalıdır). Eksik veya bilinmeyen türlerle ilgili uyarılar veya hatalar, test edilen başlık dosyasının bazı eksik #includedirektiflere ve / veya eksik ileri bildirimlere sahip olduğu anlamına gelir. İyi not: Sadece testin geçmesi, #includedirektif setinin yeterli olduğu, minimum düzeyde olmadığı anlamına gelmez .

Zaten söylenenlere ek olarak.

H dosyaları her zaman içermelidir:

• Kaynak kodu dokümantasyonu !!! En azından, çeşitli parametrelerin ve fonksiyonların dönüş değerlerinin amacı nedir.
• Başlık korumaları, #ifndef MYHEADER_H #define MYHEADER_H ... #endif

H dosyaları asla içermemelidir:

• Her türlü veri tahsisi.
• İşlev tanımları Satır içi işlevler, bazı durumlarda nadir bir istisna olabilir.
• Etiketlenmiş herhangi bir şey static.
• Typedef, uygulamanın geri kalanıyla ilgisi olmayan #fine veya sabitleri tanımlar.

(Sabit olmayan global / harici değişkenleri herhangi bir yerde kullanmak için hiçbir zaman bir neden olmadığını da söyleyebilirim, ama bu başka bir gönderi için bir tartışma.)

Muhtemelen asla asla söylemem ama, ayrıştırıldıklarında veri ve kod üreten ifadeler bir .h dosyasında olmamalıdır.

Makrolar, satır içi işlevler ve şablonlar veri veya koda benzeyebilir, ancak ayrıştırıldıkları gibi kod üretmezler, bunun yerine kullanılırlarsa. Bu öğelerin genellikle birden fazla .c veya .cpp içinde kullanılması gerekir, bu yüzden .h'ye aittirler.

Benim görüşüme göre, bir başlık dosyası karşılık gelen bir .c veya .cpp için minimum pratik arayüze sahip olmalıdır. Arayüz, #defines, class, typedef, struct tanımları, fonksiyon prototipleri ve global değişkenler için daha az tercih edilen harici tanımları içerebilir. Bununla birlikte, bir bildirim yalnızca bir kaynak dosyada kullanılıyorsa, muhtemelen .h'den dışlanmalı ve bunun yerine kaynak dosyada bulunmalıdır.

Bazıları aynı fikirde olmayabilir, ancak .h dosyaları için kişisel ölçütlerim, derlemeleri için gereken tüm diğer .h dosyalarını içermeleridir. Bazı durumlarda, bu çok fazla dosya olabilir, bu yüzden büyük bir içerme dosyası ağacı olabilecekleri dahil etmeden, işaretçileri bir sınıftaki nesnelere göstericileri kullanmamızı sağlayan sınıflara ileri bildirimler gibi dış bağımlılıkları azaltmak için bazı etkili yöntemlere sahibiz.

Başlık dosyasında aşağıdaki kuruluş bulunmalıdır:

• tip ve sabit tanımlar
• dış nesne bildirimleri
• dış işlev bildirimleri

Üstbilgi dosyaları hiçbir zaman nesne tanımları içermemeli, yalnızca tanımları ve nesne bildirimlerini yazmalıdır.

Ayrıştırıldıkça veri ve kod üreten ifadeler bir .hdosyada olmamalıdır . Benim bakış açım söz konusu olduğunda, bir üstbilgi dosyası sadece ilgili .cveya onun için en az pratik bir arayüze sahip olmalıdır .cpp.