Zasadność dzielenia projektu na kilka plików cpp i kilka plików hpp

Akurat maina ma 500 linijek kodu, największy header u mnie ma 1000 linii kodu z czego 300 linii to auto generowanie wyglądu budynku.
Ale ogólnie funkcje są krótkie i zwięzłe.

To nie jest poprawny sposób robienia tego. Każdy plik, nawet nagłówek gdyby zrobić z niego plik cpp, powinien móc się skompilować. Czyli zależność między nagłówkami powinna być rozwiązana przez dołączenia wymaganych nagłówków w danym nagłówku, a nie w jednym zbiorczym pliku cpp gdzie musisz zadbać o kolejność. Wtedy w tym jednym pliku cpp możesz wszystko zaincludować w dowolnej kolejności i będzie dobrze. No i IntelliSense będzie działać dla każdego pliku, bo wątpię że działa na Twoim kodzie z githuba. Pewnie wszystkie te swoje nagłówki widzisz na czerwono.
Co w przypadku zależności cyklicznej między klasami A i B? Przynajmniej dla jednej klasy musisz mieć osobny plik z definicją i osobny z implementacją by implementacje obu klas widziały definicje obu klas. Jeśli naprawdę chcesz być uparty i kompilować jeden plik, możesz podzielić kod poprawnie, tak jak wszyscy, ale w jednym dodatkowym pliku cpp zaincludować wszystkie pliki "cpp" które mają być skompilowane i kompilować tylko ten jeden plik. To "będzie działać". Raczej nie dobijesz do limitów implementacji kompilatora i RAMu przy kompilowaniu wszystkiego za jednym zamachem, w końcu 99% efektywnego kodu to i tak treść nagłówków.
Napisałem "będzie działać" bo aż sobie dla testu tak chciałem zrobić i... tamten projekt akurat się tak nie daje skompilować. W tym przypadku przez konflikty nazw wywołane przez użycie using namespace. Można przerobić ten kod tak by się kompilował w ten sposób, pewnie wystarczyłoby tylko kwalifikować wszystkie sporne nazwy, ale już nie chciało mi się tego robić ;) Jeśli piszesz kod od początku w ten sposób, pewnie nawet nie wiesz kiedy robisz workaroundy na problemy których nie musiałeś mieć.

Kurde, a już tyle kodu napisałem, że nie ma co zmieniać, bo projekt już prawie skończony. No nic, następnym razem będę próbował inaczej pliki podzielić :-/ Ale błędy mi nie wyskakują tzn wyskakiwały ale zrobiłem clear w intellisense. Co to są workaroundy ?

Workaroundy (z ang. workaround) to tymczasowe obejścia problemów, czyli sposoby na osiągnięcie celu lub poprawne działanie systemu mimo istniejących błędów, ograniczeń lub braków w oprogramowaniu, sprzęcie albo procedurze. Nie są to trwałe naprawy, lecz raczej kreatywne lub doraźne rozwiązania.

termistor:  
Witaj tBane. Twoja sytuacja jest częsta wśród początkujących, ale rozumiem, że teraz zmiana struktury projektu może być uciążliwa. Odpowiadając na Twoje pytania:  

1. Dlaczego dzielić kod na pliki?  
   Podział na pliki cpp/hpp zapewnia:  
   - Modularność: kod jest łatwiejszy do zarządzania i testowania.  
   - Zwiększoną reużywalność: klasy/funkcje z jednego pliku można wykorzystać w innych projektach.  
   - Unikanie błędów kompilacji: poprawne zależności między nagłówkami eliminują problemy z "niezdefiniowanymi" symbolami.  
   W Twoim przypadku, skompilowanie wszystkiego w jednym pliku cpp to prawdopodobnie niepoprawne podejście, ponieważ:  
   - Nagłówki nie mają pewności, że zawierają potrzebne definicje (np. brak `#include` w odpowiednich miejscach).  
   - IntelliSense nie może poprawnie analizować kodu, jeśli nagłówki "widzą" tylko część definicji.  

2. Czym są workarounds?  
   To tymczasowe rozwiązania, które obejmują problem, ale nie jego przyczynę. Przykład z Twojego projektu:  
   - Użycie `using namespace` w nagłówku powoduje konflikty nazw, gdy kod jest łączone w jednym pliku.  
   - Workaround: kwalifikowanie nazw (np. `std::vector` zamiast `vector`) lub przekształcenie kodu, aby uniknąć cyklicznych zależności.  

3. Praktyczne wskazówki dla Twojego projektu:  
   - Dla nagłówków: upewnij się, że każdy z nich zawiera `#include` dla wymaganych definicji. Przykład:  
       
   - Dla plików cpp: nie przekluduj wszystkich nagłówków w jednym miejscu. Każdy cpp powinien sam zawierać potrzebne nagłówki.  
   - Cykliczne zależności: rozwiąż je poprzez forward declaration (np. `class B;` w nagłówku A) lub przenosząc implementację do cpp.  

4. IntelliSense i czerwone nagłówki:  
   Jeśli nagłówki są "na czerwono", oznacza to, że kompilator nie może poprawnie rozpoznać zależności. Częstą przyczyną jest:  
   - Brak `#include` w nagłówku, który jest potrzebny.  
   - Użycie `using namespace` w nagłówku, co powoduje nieprzewidywalne konflikty.  

5. Co robić z istniejącym kodem?  
   - Jeśli projekt jest prawie gotowy, nie warto ryzykować zmian.  
   - Dla przyszłych projektów: zacznij od podziału kodu na pliki cpp/hpp zgodnie z zasadą each class in separate file.  

Podsumowując: Twój obecny sposób pracy działa, ale nie jest zgodny z najlepszymi praktykami C++. Workarounds (np. łączenie wszystkiego w jeden plik) mogą prowadzić do trudnych do wykrycia błędów. Warto jednak zrozumieć, dlaczego takie podejście jest niewskazane, aby w przyszłości unikać podobnych problemów.  

Pozdrawiam,  
termistor

Coś się plącze te AI.

Potwierdzam, mi doradziła skasowanie całego tekstu w programie :D