Zamieszanie przy dzieleniu kodu na pliki

Witam,
może od razu przejdę do rzeczy. Załóżmy, że mamy duży projekt, w którym jest kilkanaście plików z kodem, np.:
W każdym z plików (.hpp) dodajemy jakieś biblioteki. Nagle zdaliśmy sobie sprawę, że w pliku "z.cpp" będziemy potrzebowali zmiennej z klasy, która jest w pliku "a.hpp", więc dodajemy do "z.hpp" nagłówek "a.hpp". Do pliku "a.hpp" dodaliśmy wcześniej pliki "b.hpp", "c.hpp", więc plik "z.hpp" będzie wyglądał mniej więcej tak:
Po skompilowaniu projektu w pliku "z.hpp" będzie dużo niepotrzebnych rzeczy (np. kod z plików "b.hpp" i "c.hpp"), które nie są w żaden sposób używane.

Pytanie: Czy da się jakoś uniknąć takiego zamieszania? Czy w ogóle się tym przejmować, czy zostawić to kompilatorowi?
Może to i banalna sprawa, ale to mi nie daje spać ;p.

Niepotrzebnych? Skoro b.hpp i c.hpp są dołączane przez a.hpp, to pewnie są mu potrzebne. A uniknąć takiego zamieszania się da na dwa sposoby. Pierwszy - rozpisać sobie wszystkie zależności i pomyśleć, od czego zależy interfejs (czyli .hpp), a od czego implementacja (.cpp) i odpowiednio pozmieniać includy. Drugi - użyć lepszego języka.
Z tego co widzę, to ty walisz zależność w interfejsie nawet, jeśli powinna być w implementacji.

To jest coś czego chyba żadna znana książka mi nie opsuje ;) książki są pisane z myślą o nauce podstaw, a nie o tym jak należy organizować projekty itp. W końcu skąd autor książki ma wiedzieć jak to należy robić, skoro pisze na podstawie 20 innych książek nie mając o tym zielonego pojęcia :)

Niepotrzebnych? Skoro b.hpp i c.hpp są dołączane przez a.hpp, to pewnie są mu potrzebne.

b.hpp i c.hpp są potrzebne plikowi "a.hpp", ale plikowi "z.hpp", do którego dodałem "a.hpp" już nie ;p.
Drugi sposób odpada (przynajmniej na razie).

Z tego co widzę, to ty walisz zależność w interfejsie nawet, jeśli powinna być w implementacji.

Jeśli dobrze zrozumiałem, mówisz, że zamiast ".hpp" powinienem dołączać .cpp ?

b.hpp i c.hpp są potrzebne plikowi "a.hpp", ale plikowi "z.hpp", do którego dodałem "a.hpp" już nie

Czyli są potrzebne z.hpp, bo ten zależy od a.hpp, który zależy od b.hpp i c.hpp.

Jeśli dobrze zrozumiałem, mówisz, że zamiast ".hpp" powinienem dołączać .cpp ?

Nie! Mówię, że dołączasz pliki .hpp w innych .hpp nawet, jeśli wystarczyłoby dołączyć je w .cpp. Przynajmniej tak wynika z

Nagle zdaliśmy sobie sprawę, że w pliku "z.cpp" będziemy potrzebowali zmiennej z klasy, która jest w pliku "a.hpp", więc dodajemy do "z.hpp" nagłówek "a.hpp".

książki są pisane z myślą o nauce podstaw, a nie o tym jak należy organizować projekty itp.

Nie wiem, co czytałeś, ale to zdanie to bzdura jak ze Szczecina do Krakowa...

Tej opcji nie próbowałem jeszcze, ale działa ;).
Jednak teraz się zastanawiam, po co się tak męczyć - nie lepiej mieć wszystko w jednym pliku (tzn. 3: main + klasy.hpp + klasy.cpp)? Przy małych projektach (do 1000/2000 linii kodu) raczej dałoby się to w miarę odczytać. Oczywiście czas kompilacji by się zwiększył, ale przynajmniej nie byłoby takiego bałaganu ;p.

Jednak teraz się zastanawiam, po co się tak męczyć - nie lepiej mieć wszystko w jednym pliku (tzn. 3: main + klasy.hpp + klasy.cpp)?

Nie. Przynajmniej według tych od wszelkich coding standards, jak chcesz to sobie olewaj, ale potem tylko do siebie miej pretensje, że stworzyłeś kod, który stanowi zagadkę dla jasnowidza ;)

Przy małych projektach (do 1000/2000 linii kodu) raczej dałoby się to w miarę odczytać.

Tja, ale to zwykle kwestia czasu, jak z tego tysiąca linii zrobi się dziesięć, albo więcej, tysięcy ;)

Oczywiście czas kompilacji by się zwiększył

Zmniejszyłby się. W C++ (i C, ale w nim to nie boli, bo język nie jest skomplikowany i się szybko kompiluje) sprawa z podziałem kodu na moduły jest taka poryta, że kompilator musi przez cały czas kompilować to samo - taka już specyfika #include. Oczywiście jeśli temat dotyczyłby jakiegokolwiek sensownego języka, to miałbyś rację ;)

Ehhh, czyli jednak będę się musiał trochę pomęczyć... No cóż, skoro nie ma innej opcji (dostępnej w C++) ;p.
Dzięki za zainteresowanie ;).