C / C ++ obejmują kolejność plików nagłówkowych

W jakiej kolejności należy podać pliki, tj. Jakie są powody umieszczania jednego nagłówka przed drugim?

Na przykład, czy pliki systemowe, STL i Boost idą przed czy po lokalnych plikach dołączanych?

Nie sądzę, aby istniało zalecane zamówienie, o ile się kompiluje! Irytujące jest to, że niektóre nagłówki wymagają najpierw dołączenia innych nagłówków ... To jest problem z samymi nagłówkami, a nie z kolejnością dołączania.

Moje osobiste preferencje to przejście z lokalnego na globalny, każdy podsekcja w kolejności alfabetycznej, tj .:

1. plik h odpowiadający temu plikowi CPP (jeśli dotyczy)
2. nagłówki z tego samego komponentu,
3. nagłówki z innych komponentów,
4. nagłówki systemowe.

Moim uzasadnieniem dla 1. jest to, że powinno to udowodnić, że każdy nagłówek (dla którego jest procesor) może być #included bez wymagań wstępnych (terminus technicus: nagłówek jest „samowystarczalny”). A reszta wydaje się płynąć stamtąd logicznie.

Należy pamiętać, że nagłówki nie powinny być zależne od włączenia innych nagłówków. Jednym ze sposobów zapewnienia tego jest dołączenie nagłówków przed innymi nagłówkami.

Wspomina o tym w szczególności „Thinking in C ++”, nawiązując do „Lakos C ++ Software Design”:

Można uniknąć ukrytych błędów użytkowania, upewniając się, że plik .h komponentu analizuje się sam - bez deklaracji lub definicji dostarczonych zewnętrznie ... Dołączenie pliku .h jako pierwszej linii pliku .c gwarantuje, że żaden kluczowy fragment informacji właściwych dla fizycznego interfejsu komponentu brakuje w pliku .h (lub, jeśli tak, to dowiesz się o tym, jak tylko spróbujesz skompilować plik .c).

To znaczy, uwzględnij w następującej kolejności:

1. Prototyp / nagłówek interfejsu dla tej implementacji (tzn. Plik .h / .hh, który odpowiada temu plikowi .cpp / .cc).
2. Inne nagłówki z tego samego projektu, w razie potrzeby.
3. Nagłówki z innych niestandardowych bibliotek niesystemowych (na przykład Qt, Eigen itp.).
4. Nagłówki z innych „prawie standardowych” bibliotek (na przykład Boost)
5. Standardowe nagłówki C ++ (na przykład iostream, funkcjonalne itp.)
6. Standardowe nagłówki C (na przykład cstdint, dirent.h itp.)

Jeśli któryś z nagłówków ma problem z dołączeniem do tej kolejności, napraw je (jeśli twoje) lub nie używaj ich. Biblioteki bojkotu, które nie piszą czystych nagłówków.

C ++ przewodnik redakcyjny Google twierdzi, prawie na odwrót, ze naprawdę nie ma uzasadnienia w ogóle; Osobiście wolę podejście Lakos.

Przestrzegam dwóch prostych zasad, które pozwalają uniknąć ogromnej większości problemów:

1. Wszystkie nagłówki (i wszystkie pliki źródłowe) powinny zawierać to, czego potrzebują. Powinny one nie polegać na swoich użytkowników, w tym rzeczy.
2. Jako dodatek, wszystkie nagłówki powinny zawierać strażników, aby nie zostały one uwzględnione wiele razy przez zbyt ambitne zastosowanie powyższej zasady 1.

Przestrzegam również wytycznych:

1. Najpierw dołącz nagłówki systemowe (stdio.h itp.) Z linią podziału.
2. Pogrupuj je logicznie.

Innymi słowy:

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

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

Chociaż będąc wytycznymi, jest to subiektywna sprawa. Z drugiej strony reguły, egzekwuję sztywno, nawet do tego stopnia, że ​​udostępniam pliki nagłówkowe „wrapper” z włączonymi strażnikami i pogrupowane, jeśli jakiś wstrętny zewnętrzny programista nie podzieli się moją wizją :-)

Aby dodać własną cegłę do ściany.

1. Każdy nagłówek musi być samowystarczalny, który można przetestować tylko wtedy, gdy zostanie dołączony przynajmniej raz
2. Nie należy omyłkowo modyfikować znaczenia nagłówka innej firmy, wprowadzając symbole (makro, typy itp.)

Więc zwykle tak wyglądam:

// 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"

Każda grupa oddzielona pustą linią od następnej:

• Najpierw nagłówek odpowiadający temu plikowi cpp (kontrola poprawności)
• Nagłówki systemowe
• Nagłówki innych firm, uporządkowane według kolejności zależności
• Nagłówki projektu
• Nagłówki prywatne projektu

Zauważ też, że oprócz nagłówków systemowych każdy plik znajduje się w folderze o nazwie jego przestrzeni nazw, tylko dlatego, że łatwiej jest go wyśledzić w ten sposób.

Polecam:

1. Nagłówek budowanego modułu .cc. (Pomaga upewnić się, że każdy nagłówek w projekcie nie ma niejawnych zależności od innych nagłówków w projekcie).
2. Pliki systemowe C.
3. Pliki systemowe C ++.
4. Platforma / system operacyjny / inne pliki nagłówkowe (np. Win32, gtk, openGL).
5. Inne pliki nagłówkowe z twojego projektu.

I oczywiście, w miarę możliwości, kolejność alfabetyczna w każdej sekcji.

Zawsze używaj deklaracji przesyłania dalej, aby uniknąć niepotrzebnych #includeznaków w plikach nagłówka.

Jestem prawie pewien, że nie jest to zalecana praktyka nigdzie w zdrowym świecie, ale lubię, aby system zawierał według długości nazwy pliku, posortowanej leksykalnie w tej samej długości. Tak jak:

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

Myślę, że dobrym pomysłem jest dołączanie własnych nagłówków przed innymi ludźmi, aby uniknąć wstydu związania z kolejnością dołączania.

To nie jest subiektywne. Upewnij się, że nagłówki nie polegają na #includebw określonej kolejności. Możesz być pewien, że nie ma znaczenia, w jakiej kolejności dołączasz nagłówki STL lub Boost.

Najpierw dołącz nagłówek odpowiadający .cpp ... innymi słowy, source1.cpppowinien zawierać source1.hprzed dołączeniem czegokolwiek innego. Jedyny wyjątek, jaki mogę wymyślić, to użycie MSVC ze wstępnie skompilowanymi nagłówkami, w którym to przypadku musisz dołączyćstdafx.h wszystko inne.

Uzasadnienie: Uwzględnienie source1.hwcześniejszych plików gwarantuje, że może on działać samodzielnie bez swoich zależności. Jeśli source1.hpóźniej przyjmie zależność, kompilator natychmiast powiadomi Cię o dodaniu wymaganych deklaracji przesyłania dalej source1.h. To z kolei zapewnia, że ​​nagłówki mogą być uwzględniane w dowolnej kolejności przez osoby pozostające na ich utrzymaniu.

Przykład:

źródło1.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
...

Użytkownicy MSVC: Zdecydowanie polecam korzystanie ze wstępnie skompilowanych nagłówków. Więc przenieś wszystkie #includedyrektywy dla standardowych nagłówków (i innych nagłówków, które nigdy się nie zmienią) na stdafx.h.

Uwzględnij od najbardziej specyficznego do najmniej określonego, zaczynając od odpowiedniego pliku .hpp dla pliku .cpp, jeśli taki istnieje. W ten sposób zostaną ujawnione wszelkie ukryte zależności w plikach nagłówkowych, które nie są samowystarczalne.

Komplikuje to użycie wstępnie skompilowanych nagłówków. Jednym ze sposobów obejścia tego jest to, że nie czyniąc specyficznego dla kompilatora projektu, można użyć jednego z nagłówków projektu jako wstępnie skompilowanego pliku dołączanego nagłówka.

To trudne pytanie w świecie C / C ++ z tak wieloma elementami poza standardem.

Myślę, że kolejność plików nagłówkowych nie stanowi poważnego problemu, o ile się kompiluje, jak powiedział Squelart.

Moje pomysły są następujące: jeśli nie ma konfliktu symboli we wszystkich tych nagłówkach, każda kolejność jest OK, a problem zależności nagłówka można rozwiązać później, dodając #include wiersze do wadliwego .h.

Prawdziwy kłopot powstaje, gdy jakiś nagłówek zmienia swoje działanie (sprawdzając warunki # if) zgodnie z nagłówkami powyżej.

Na przykład w pliku stddef.h w VS2005 znajduje się:

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

Teraz problem: jeśli mam niestandardowy nagłówek („custom.h”), który musi być używany z wieloma kompilatorami, w tym starszymi, które nie zawierają offsetofnagłówków systemowych, powinienem napisać w moim nagłówku:

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

I pamiętaj, aby poinformować użytkownika #include "custom.h" po wszystkich nagłówkach systemowych, w przeciwnym razie wiersz offsetofw pliku stddef.h spowoduje błąd redefinicji makra.

Modlimy się, aby nie spotkać się z takimi przypadkami w naszej karierze.