C / C ++ başlık dosyası sırasını içerir

Hangi sipariş dosyaları belirtilmelidir, yani bir üstbilgiyi diğerine eklemenin nedenleri nelerdir?

Örneğin, sistem dosyaları, STL ve Boost yerel içerme dosyalarından önce mi sonra mı gidiyor?

Derlediği sürece önerilen bir sipariş olduğunu sanmıyorum! Can sıkıcı olan, bazı başlıkların önce diğer başlıkların dahil edilmesini gerektirmesidir ... Bu, başlıkların sırası ile değil başlıkların kendileriyle ilgili bir sorundur.

Kişisel tercihim yerelden küresel olana, her alt bölümü alfabetik sırayla, yani:

1. Bu cpp dosyasına karşılık gelen h dosyası (varsa)
2. aynı bileşenden başlıklar,
3. diğer bileşenlerden başlıklar,
4. sistem başlıkları.

Benim için #includegerekçem , her başlığın (bir cpp olduğu) önkoşullar olmadan (terminus technicus: header "müstakil" olduğunu) kanıtlaması gerektiğidir . Ve geri kalanlar mantıklı bir şekilde oradan akıyor gibi görünüyor.

Akılda tutulması gereken en önemli şey, başlıklarınızın önce dahil edilen diğer başlıklara bağlı olmaması gerektiğidir. Bunu sağlamanın bir yolu da başlıklarınızı diğer başlıklardan önce eklemektir.

"C ++ 'da Düşünmek" özellikle bundan bahsediyor ve Lakos'un "Büyük Ölçekli C ++ Yazılım Tasarımına" atıfta bulunuyor:

Bir bileşenin .h dosyasının harici olarak sağlanan bildirimler veya tanımlar olmadan kendi kendine ayrıştırılmasını sağlayarak gizli kullanım hataları önlenebilir. .H dosyasını .c dosyasının ilk satırı olarak dahil etmek, kritik bir parçanın bileşeninin fiziksel arabirimine özgü bilgiler .h dosyasında eksiktir (veya varsa, .c dosyasını derlemeye çalıştığınızda bunu öğreneceksiniz).

Yani, aşağıdaki sırayla ekleyin:

1. Bu uygulamanın prototip / arabirim başlığı (yani, bu .cpp / .cc dosyasına karşılık gelen .h / .hh dosyası).
2. Gerektiği gibi aynı projeden diğer başlıklar.
3. Diğer standart olmayan, sistem dışı kitaplıkların başlıkları (örneğin, Qt, Eigen, vb.).
4. Diğer "neredeyse standart" kitaplıkların başlıkları (örneğin, Boost)
5. Standart C ++ başlıkları (örneğin, iostream, fonksiyonel vb.)
6. Standart C başlıkları (örneğin, cstdint, dirent.h, vb.)

Başlıklardan herhangi birinin bu siparişe dahil edilmeyle ilgili bir sorunu varsa, bunları düzeltin (sizinkini) veya kullanmayın. Temiz başlık yazmayan kütüphaneleri boykot edin.

Google'ın C ++ stil kılavuzu savunuyor neredeyse hiç gerçekten hiçbir gerekçe ile, ters; Şahsen Lakos yaklaşımını destekleme eğilimindeyim.

Sorunların büyük çoğunluğunu önleyen iki basit kurala uyuyorum:

1. Tüm üstbilgiler (ve aslında herhangi bir kaynak dosya) ihtiyaç duyduklarını içermelidir. Onlar should not şeylere dahil kullanıcılarını güveniyor.
2. Ek olarak, tüm üstbilgilerin yukarıdaki kural 1'in aşırı iddialı uygulamasıyla birden fazla kez dahil edilmemeleri için korumaları içermesi gerekir.

Ayrıca aşağıdaki yönergeleri de takip ediyorum:

1. Önce sistem başlıklarını (stdio.h, vb.) Bir bölme çizgisiyle ekleyin.
2. Bunları mantıksal olarak gruplandırın.

Diğer bir deyişle:

#include <stdio.h>
#include <string.h>

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

Her ne kadar, rehber olmak, bu öznel bir şeydir. Diğer yandan, kurallar, sıkıca, hatta 'sarıcı' başlık dosyaları korumaları ve gruplandırılmış bazı iğrenç üçüncü taraf geliştirici vizyonum abone olmazsa içerir sağlamak için bile zorlamak :-)

Duvara kendi tuğlamı eklemek için.

1. Her bir başlığın kendi kendine yeterli olması gerekir; bu, yalnızca ilk önce en az bir kez dahil edilmişse test edilebilir
2. Semboller (makro, türler vb.) Tanıtarak üçüncü taraf üstbilgisinin anlamını yanlışlıkla değiştirmemelisiniz.

Bu yüzden genellikle şöyle giderim:

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

Her grup bir sonrakinden boş bir satırla ayrılır:

• Önce bu cpp dosyasına karşılık gelen başlık (akıl sağlığı kontrolü)
• Sistem başlıkları
• Bağımlılık sırasına göre düzenlenmiş üçüncü taraf başlıkları
• Proje başlıkları
• Proje özel başlıkları

Ayrıca, sistem başlıklarının yanı sıra, her dosyanın ad alanının adıyla bir klasörde olduğunu unutmayın, çünkü bunları bu şekilde izlemek daha kolaydır.

Ben tavsiye ediyorum:

1. Oluşturduğunuz .cc modülünün başlığı. (Projenizdeki her üstbilginin, projenizdeki diğer üstbilgilere örtülü bağımlılıkları olmamasına yardımcı olur.)
2. C sistem dosyaları.
3. C ++ sistem dosyaları.
4. Platform / OS / diğer başlık dosyaları (örn. Win32, gtk, openGL).
5. Projenizdeki diğer başlık dosyaları.

Ve elbette, mümkün olan her bölümdeki alfabetik sıra.

#includeBaşlık dosyalarınızda gereksiz durumlardan kaçınmak için her zaman ileri bildirimler kullanın .

Bunun aklı başında dünyanın herhangi bir yerinde tavsiye edilen bir uygulama olmadığından eminim, ancak sisteme aynı uzunluktaki sözcük olarak sıralanan dosya adı uzunluğuna kadar sıralamayı seviyorum. Şöyle ki:

#include <set>
#include <vector>
#include <algorithm>
#include <functional>

Sanırım içerme düzenine bağımlılıktan utanmaktan kaçınmak için diğer kişilerin önüne kendi başlıklarınızı eklemek iyi bir fikirdir.

Bu öznel değil. Başlıklarınızın #includebelirli bir sırada d olmasına bağlı olmadığından emin olun . STL veya Boost başlıklarını hangi sırayla eklediğinizin önemli olmadığından emin olabilirsiniz.

Öncelikle .cpp ... 'e karşılık gelen üstbilgiyi, başka bir şey eklemeden önce source1.cppiçermelidir source1.h. Aklıma gelen tek istisna, MSVC'yi önceden derlenmiş başlıklarla kullanırken, bu durumda stdafx.hbaşka bir şeyden önce dahil etmek zorunda kalırsınız .

Muhakeme: dahil source1.ho 's bağımlılıkları olmadan tek başına var olamayacağını başka dosyalardan önce garantiler. Daha source1.hsonraki bir tarihte bir bağımlılık alırsanız , derleyici derhal gerekli ileri bildirimleri eklemeniz için sizi uyaracaktır source1.h. Bu da başlıkların bağımlıları tarafından herhangi bir sıraya dahil edilmesini sağlar.

Misal:

source1.h

class Class1 {
    Class2 c2;    // a dependency which has not been forward declared
};

source1.cpp

#include "source1.h"    // now compiler will alert you saying that Class2 is undefined
                    // so you can forward declare Class2 within source1.h
...

MSVC kullanıcıları: Önceden derlenmiş başlıklar kullanmanızı önemle tavsiye ederim. Bu nedenle, #includestandart başlıklar (ve asla değişmeyecek diğer başlıklar) için tüm yönergeleri taşıyın stdafx.h.

Varsa, .cpp için karşılık gelen .hpp ile başlayarak en spesifik olandan en az spesifik olana kadar ekleyin. Bu şekilde, başlık dosyalarındaki kendi kendine yeterli olmayan gizli bağımlılıklar ortaya çıkar.

Bu, önceden derlenmiş başlıkların kullanımı ile karmaşıktır. Bunun bir yolu, projenizi derleyiciye özgü yapmadan, proje başlıklarından birini önceden derlenmiş başlık içerme dosyası olarak kullanmaktır.

C / C ++ dünyasında zor bir sorudur ve standardın ötesinde pek çok unsuru vardır.

Bence başlık dosya sırası derliyordu gibi derliyorum ciddi bir sorun değildir, dedi.

Benim düşüncelerim: Tüm bu başlıklarda sembol çakışması yoksa, herhangi bir sipariş tamamdır ve başlık bağımlılığı sorunu daha sonra kusurlu .h'ye #include satırları eklenerek düzeltilebilir.

Gerçek zorluk, bazı üstbilgiler yukarıdaki başlıklara göre (#if koşullarını kontrol ederek) eylemini değiştirdiğinde ortaya çıkar.

Örneğin, VS2005'teki stddef.h dosyasında:

#ifdef  _WIN64
#define offsetof(s,m)   (size_t)( (ptrdiff_t)&(((s *)0)->m) )
#else
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

Şimdi sorun: offsetofKendi sistem başlıklarında sağlamayan bazı eski derleyiciler de dahil olmak üzere birçok derleyici ile kullanılması gereken özel bir üstbilgi ("custom.h") varsa, üstbilgime yazmalıyım:

#ifndef offsetof
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

Ve kullanıcıya tüm sistem başlıklarından #include "custom.h" sonraoffsetof bahsettiğinizden emin olun , aksi takdirde stddef.h satırı bir makro yeniden tanımlama hatası verir.

Kariyerimizde bu tür olaylarla daha fazla karşılaşmamak için dua ediyoruz.