W jaki sposób organizujesz nagłówki STL?

Question

Pracuję nad dużym projektem korzystającym ze STL i mając pytanie dotyczące preferowanego sposobu organizacji STL #includes.

• Wolisz #include każdego nagłówka w pliku źródłowym, którego jest użyty. Na przykład, jeśli oba wymagają foo.cpp i, oba będą #include <string>.
• Wolisz mieć pojedynczy plik nagłówkowy, który zawiera wszystkie nagłówki STL używane przez projekt (to znaczy dodaje je do skompilowanego nagłówka MS 'stdafx.h').

Zaletą pierwszej metody jest to, że plik .cpp jest niezależną jednostką i może być używany w innym projekcie, nie martwiąc się, że jesteś brakuje #include. Zaletami drugiej metody jest to, że możesz użyć skompilowanych nagłówków kompilatorów i możesz zawinąć STL #includes w pragmas, który wyłącza niektóre ostrzeżenia (na przykład niektóre nagłówki Boost będą powodować ostrzeżenia podczas kompilacji na poziomie 4).

Które wolisz używać?

Answer 1

Dołączam tylko pliki nagłówkowe, które są naprawdę potrzebne w każdym źródle, a nie nagłówki "catch all", aby utrzymać zależności (a zatem czasy kompilacji) na jak najniższym poziomie.

Prekompilowane nagłówki mogą działać niezależnie od tego (tj. Polegam na wstępnie skompilowanych nagłówkach, aby przyspieszyć proces kompilacji, a nie uzyskać deklaracji). Tak więc nawet jeśli coś zostanie zadeklarowane za pośrednictwem dołączonych nagłówków prekompilowanych, nadal umieszczam "regularny" nagłówek, który zostanie pominięty przez mechanizm ochrony zawartości i nie doda nic znaczącego do czasów kompilacji.

Jako prekompilowane nagłówki są specyficzne dla kompilatora. Optymalizacja/zmiana prekompilowanych nagłówków nie powinna w moim odczuciu wpływać na prawidłowe funkcjonowanie kodu.

Główną zaletą posiadania zależności na jak najniższym poziomie jest to, że refaktoring staje się łatwiejsze (lub raczej: niewykonalne)

Świetna książka o tym wszystkim jest Large Scale C++ Design from Lakos

Answer 2

Całkowicie zgadzam się z sugestią dla książki Johna Lakos duża Skaluj C++ Design.

Należy zadeklarować wszystkie nagłówki potrzebne do pliku, czy .h lub .cpp, w samym pliku. Nie należy polegać na efektach ubocznych plików zawartych w innych plikach nagłówkowych.

Posiadanie dużej listy nagłówków wszystkich elementów niepotrzebnie zwiększa zależności i sprawia, że ​​konstrukcja jest bardzo krucha.

O, jeszcze jedna rzecz nigdy nie używa deklaracji w pliku nagłówkowym. Używaj ich tylko w swoich plikach implementacyjnych, plikach .cpp.

HTH.

okrzyki,

Rob

Answer 3

Co mogę zrobić, to obejmują wszystkie nagłówki STL Zamierzam potrzebne w całym projekcie w moim pojedynczego precompiled header, zwykle domyślną stdafx.h. Prekompilowany nagłówek jest de facto pierwszą rzeczą, którą należy skonfigurować w projekcie, w tym wszystkie nagłówki STL/boost// platform i biblioteki stron trzecich.

STL & Podbicie STL są uporządkowane w przestrzeni nazw, więc nie powodują one żadnych pomyłek ani nakładek.

W nagłówkach zazwyczaj używam pełnych nazw, ale w plikach źródłowych należy używać przestrzeni nazw x, gdy jest to właściwe.

Answer 4

Można łączyć te dwie metody:

mieć zarówno .cpp - pliki należą, a także dodać go do stdafx.h. To nadal da ci optymalizację PCH.

Plik .cpp nadal musi # zawierać "stdafx.h", więc jego niezależność jest dyskusyjna. Jednak zależność jest wyraźnie określona, ​​a usunięcie pliku stdafx.h jest prostsze niż znalezienie wszystkich brakujących elementów. Również standardowe nagłówki - tak jak powinny wyglądać wszystkie nagłówki - upewnij się, że nie są uwzględnione dwukrotnie.

---

Generalnie zgadzam się z podejściem do każdego pliku „niezależny”, to znaczy, gdy .cpp dodaje do innego projektu lub .h jest włączone, to dba o jego zależnościami.

---

Pamiętaj, że PCH to kompromis, mogą stać się ogromne. Posiadanie znacznie niewykorzystanego kodu w PCH może faktycznie spowolnić twoje kompilacje. Szybkie dyski bardzo pomagają :)

Należy również pamiętać, że włączenie prekompilowanych nagłówków w MSVC przynajmniej w niektórych wersjach faktycznie zmienia przetwarzanie: deklaracje przed #include "stdafx.h" są ignorowane, więc to musi być twoim pierwszym nie komentującym stwierdzeniem. Brzydka pułapka.