Sposób logicznego porządkowania plików źródłowych w C++

Question

Moje okienko z plikami źródłowymi szybko się rozwija (pod względem liczby plików w moim projekcie) i robi się trochę kłopotliwe, aby szybko zlokalizować konkretny plik źródłowy, do którego muszę uzyskać dostęp w dowolnym miejscu. dany czas. Używam C++ Buildera Embarcadero, ale napotkałem ten problem także w innych IDE C++.

W Javie często używam pakietów do tworzenia logicznych podziałów mojego kodu źródłowego, szczególnie gdy mamy do czynienia z dużą liczbą plików źródłowych w jednym projekcie. Chociaż nie jest to oczywiście jedyny cel pakietów Java, są one bardzo przydatne w tym zakresie.

Czy ktoś ma jakieś pomysły na temat tego, jak mogę osiągnąć podobną funkcjonalność w C++? Czy powinienem podzielić moje źródło na foldery fizyczne? Czy C++ Builder oferuje jakąś funkcję wirtualnego folderu/grupowania, której po prostu nie widzę? Wszelkie pomysły są doceniane i dziękuję.

Answer 1

Generalnie polecam nie używać (tylko) IDE lub składni języka do organizowania kodu źródłowego. Po pierwsze przywiązujesz się do środowiska: dobrze zorganizowany w IDE, niezorganizowany w pliku, a nadejdzie dzień, w którym możesz chcieć użyć środowiska innego ...

Z tego powodu zazwyczaj używam wszystkie trzy sposoby organizowania mojego źródła w tym samym czasie: Oddzielam moje źródło na moduły funkcjonalne, tj. klasy powiązane. Każdy moduł otrzymuje własny obszar nazw, folder fizyczny i folder IDE. (W moim przypadku, używając CMake i source_group() wygenerować pliki projektu IDE razie potrzeby. - osobiście wolał linii poleceń Vima i „make”)

Stąd czy patrzę na projekcie z poziomu IDE, z wiersz poleceń lub z dziennika kompilacji foo/bar.cpp to foo/bar.cpp to foo :: bar, minimalizujący zamieszanie dookoła.

Faktycznie, mój obecnie preferowane ustawienie dodatkowo dzieli każde katalogu modułu do <module>/<Class>.hpp lub <module>/src/<Class>.hpp w zależności od tego, czy klasa jest używana poza własnym modułem lub nie, <module>/src/<Class>.cpp i <module>/test/<Class>Tu.cpp. Namespace to oczywiście <module>::<Class>.

Ale w ostatecznym rozrachunku zależy to w dużym stopniu od gustu współpracowników i od zakresu projektu.

Answer 2

Tworzę projekty, aby wszystkie moje pliki były łatwo dostępne. Jest to najprostszy sposób uporządkowania, wraz z jasnymi nazwami klas/plików.

Answer 3

ten sposób Ja toczę:

PROJECT_NAME 
|-- build // This is DVCS ignored but has all the built intermediates and final binaries 
| |-- release // These are the different build profiles 
| |-- debug 
| |-- profile 
| `-- coverage 
|-- bin // For binary source code 
| `-- hello_world 
|  |-- doc 
|  |-- inc 
|  |-- src 
|  |-- tests 
|  `-- build_script // Builds binary into the build folder 
|-- include // Public headers for the library 
| `-- these 
|  `-- folders 
|   `-- represent 
|    `-- namespaces 
|     `-- my_awesome_class.hpp 
|-- lib // library source code 
| |-- these 
| | `-- folders 
| |  `-- represent 
| |   `-- namespaces 
| |    |-- inc // Private headers 
| |    | `-- my_private_class.hpp // internal class 
| |    |-- src // Source code for this namespace 
| |    | |-- posix 
| |    | | `-- my_awesome_class.cpp // posix specific source code 
| |    | |-- nt 
| |    | | `-- my_awesome_class.cpp // nt specific source code 
| |    | |-- my_private_class.cpp // non-visibile class 
| |    | `-- my_awesome_class.cpp // cross platform source code 
| |    |-- tests // Unit tests 
| |    | `-- my_awesome_class.cpp // builds a test executable for the library 
| |    `-- doc // Documentation for this namespace 
| |     `-- namespace.dox 
| `-- build_script // Builds binary into the build folder 
|-- doc // Documentation files 
| |-- main_page.dox 
| `-- namespace.dox 
`-- build_script // Builds the source code into the build folder 

Reprezentuje klasę these::folders::represent::namespaces::MyAwesomeClass który ma posix i NT specyficzny kod źródłowy (jak również kod źródłowy generic) Plus znajduje się prywatny these::folders::represent::namespaces::MyPrivateClass która jest używana wewnętrznie w biblioteka, nagłówki nie są publiczne i visibility symboli klasy są ukryte.

Zostało to bardzo dobrze skalowane i zapewnia łatwe lokalizowanie plików.