Dlaczego nie połączyć plików źródłowych C przed kompilacją? [duplikat]

Ty mógłbyś to zrobić, ale lubimy rozdzielać programy C na oddzielnejednostki tłumaczeniowe, głównie dlatego, że:

1. Przyspiesza budowanie. Wystarczy tylko odbudować pliki, które się zmieniły, a te mogą być połączone z innymi skompilowanymi plikami, aby utworzyć ostateczny program.

2. Biblioteka standardowa C składa się z wstępnie skompilowanych komponentów. Naprawdę chcesz to przekompilować?

3. Łatwiej współpracować z innymi programistami, jeśli baza kodu jest podzielona na różne pliki.

• dzięki modułowości możesz udostępniać swoją bibliotekę bez udostępniania kodu.
• w przypadku dużych projektów, jeśli zmienisz pojedynczy plik, skończy się to kompilowanie całego projektu.
• może zabraknąć pamięci łatwiej, gdy próbujesz skompilować duże projekty.
• możesz mieć kołowe zależności w modułach, modułowość pomaga w ich utrzymaniu.

Mogą być pewne korzyści w twoim podejściu, ale dla języków takich jak C, kompilowanie każdego modułu sprawia, że więcej sens.

Twoje podejście do konkatenacji .pliki c są całkowicie zepsute:

• Mimo że polecenie cat *.c > to_compile.c umieści wszystkie funkcje w jednym pliku, kolejność ma znaczenie: każda funkcja musi być zadeklarowana przed jej pierwszym użyciem.

  Oznacza to, że masz zależności między swoimi .pliki c, które wymuszają określony porządek. Jeśli Twoje polecenie konkatenacji nie dotrzyma tego rozkazu, nie będziesz w stanie skompilować wyniku.

  Również, jeśli masz dwie funkcje, które rekurencyjnie używać siebie, nie ma absolutnie żadnego sposobu na napisanie deklaracji forward dla co najmniej jednej z dwóch. Równie dobrze możesz umieścić te deklaracje w pliku nagłówkowym, w którym ludzie oczekują ich znalezienia.

• Kiedy połączysz wszystko w jeden plik, wymusisz pełną przebudowę za każdym razem, gdy zmieni się pojedyncza linia w projekcie.

  Z klasykiem .c/.H split compilation approach, zmiana implementacji funkcji wymaga rekompilacja dokładnie jednego pliku, podczas gdy zmiana nagłówka wymaga rekompilacji plików, które faktycznie zawierają ten nagłówek. Może to z łatwością przyspieszyć odbudowę po niewielkiej zmianie o współczynnik 100 lub więcej (w zależności od liczby.pliki c).

• Tracisz wszystkie możliwości kompilacji równoległej , gdy połączysz wszystko w jeden plik.

  Czy duży, 12-rdzeniowy procesor z włączoną hyper-threading? Szkoda, Twój konkatenowany plik źródłowy jest kompilowany przez pojedynczy wątek. Właśnie straciłeś przyspieszenie o czynnik większy niż 20... Ok, to jest ekstremalny przykład, ale mam już oprogramowanie do budowania z make -j16 i mówię ci, może to zrobić ogromną różnicę.

• Czasy kompilacji są zazwyczaj , a nie liniowe.

  Zwykle Kompilatory zawierają co najmniej pewne algorytmy, które mają kwadratowe zachowanie środowiska wykonawczego. W związku z tym zwykle istnieje pewien próg, od którego na zbiorczej kompilacji jest w rzeczywistości wolniejsza od kompilacji niezależnych części.

  Oczywiście dokładna lokalizacja tego progu zależy od kompilatora i FLAG optymalizacji, które mu przekazujesz, ale widziałem, że kompilator zajmuje ponad pół godziny na jednym ogromnym pliku źródłowym. Nie chcesz mieć takiej przeszkody w pętli change-compile-test.

Nie popełnij błędu: nawet jeśli chodzi o te wszystkie problemy, są ludzie, którzy używają .konkatenacja pliku c w praktyce oraz niektórzy programiści C++ dostają się prawie do tego samego punktu, przenosząc wszystko do szablonów (tak, że implementacja znajduje się w .plik hpp i nie ma powiązanych .plik cpp), pozwalając preprocesorowi wykonać konkatenację. Nie rozumiem, jak mogą ignorować te problemy, ale tak jest.

Należy również zauważyć, że wiele z tych problemów stają się widoczne tylko przy większych rozmiarach projektu. Jeśli twój projekt ma mniej niż 5000 linii kodu, to nadal nie ma znaczenia, w jaki sposób go skompilujesz. Ale jeśli masz więcej niż 50000 linii kodu, zdecydowanie potrzebujesz Systemu Budowania, który obsługuje Kompilacje przyrostowe i równoległe. W przeciwnym razie marnujesz czas pracy.

Ponieważ dzielenie rzeczy jest dobrym projektem programu. Dobry projekt programu polega na modułowości, autonomicznych modułach kodu i ponownej użyteczności kodu. Jak się okazuje, zdrowy rozsądek zaprowadzi cię bardzo daleko podczas projektowania programu: rzeczy, które nie należą do siebie, nie powinny być umieszczone razem.

Umieszczenie niezwiązanego kodu w różnych jednostkach tłumaczeniowych oznacza, że można zlokalizować zakres zmiennych i funkcji w jak największym stopniu.

Łączenie rzeczy razem tworzy tight coupling , czyli niezręczne zależności między plikami kodu, które naprawdę nie powinny nawet wiedzieć o ich istnieniu. Dlatego " globalny.h", który zawiera wszystkie elementy w projekcie, jest złą rzeczą, ponieważ tworzy ścisłe powiązanie między każdym niezwiązanym plikiem w całym projekcie.

Załóżmy, że piszesz firmware do sterowania samochodem. Jeden moduł w programie steruje samochodowym radiem FM. Następnie ponownie użyj kodu radiowego w innym projekcie, aby kontrolować radio FM w smartfonie. A potem twój kod radiowy się nie skompiluje, ponieważ nie może znaleźć hamulców, kół, biegów itp. Rzeczy, które nie mają najmniejszego sensu dla radia FM, nie mówiąc już o inteligentnym telefonie.

Co gorsza, jeśli masz ciasne połączenie, błędy nasilają się w całym programie, zamiast pozostawać lokalnie w module, w którym znajduje się błąd. To sprawia, że konsekwencje błędów są znacznie poważniejsze. Wpisujesz błąd w kodzie radia FM, a następnie nagle hamulce samochodu przestają działać. Nawet jeśli nie dotknąłeś kodu hamulca z aktualizacją, która zawierała błąd.

Jeśli błąd w jednym module łamie całkowicie niezwiązane z nim rzeczy, to prawie na pewno jest to spowodowane słabą konstrukcją programu. A pewnym sposobem na osiągnięcie słabego projektu programu jest połączenie wszystkiego w projekcie w jedną wielką plamę.

Pliki nagłówkowe powinny definiować interfejsy - jest to pożądana konwencja do naśladowania. Nie są one przeznaczone do deklarowania wszystkiego, co znajduje się w odpowiednim pliku .c lub grupie plików .c. Zamiast tego deklarują wszystkie funkcje w plikach .c, które są dostępne dla ich użytkowników. Dobrze zaprojektowany plik .h zawiera podstawowy dokument interfejsu wystawiony przez KOD w pliku .c, nawet jeśli nie ma w nim ani jednego komentarza. Jednym ze sposobów podejścia do projektowania modułu C jest napisanie najpierw plik nagłówkowy, a następnie zaimplementuj go w jednym lub więcej plikach .c.

Następstwo: funkcje i struktury danych wewnętrzne implementacji pliku .c zwykle nie należą do pliku nagłówkowego. Możesz potrzebować deklaracji forward, ale powinny one być lokalne, a wszystkie zmienne i funkcje zadeklarowane i zdefiniowane powinny być static: jeśli nie są częścią interfejsu, linker nie powinien ich widzieć.

Głównym powodem jest czas kompilacji. Skompilowanie jednego małego pliku po jego zmianie może zająć niewiele czasu. Jeśli jednak skompilujesz cały projekt za każdym razem, gdy zmienisz jedną linię, skompilujesz - na przykład-10 000 plików za każdym razem, co może trwać znacznie dłużej.

Jeśli masz - jak w powyższym przykładzie-10 000 plików źródłowych, a kompilowanie jednego zajmuje 10 ms, to cały projekt buduje się stopniowo (po zmianie pojedynczego pliku) albo w (10 ms + linkowanie czas), jeśli skompilujesz tylko ten zmieniony plik, lub (10 ms * 10000 + krótki czas łączenia), jeśli skompilujesz wszystko jako pojedynczy, skonkatenowany obiekt blob.

Podczas gdy możesz napisać swój program w sposób modułowy i zbudować go jako pojedynczą jednostkę tłumaczeń, ominiesz wszystkie mechanizmy, które C dostarcza, aby wymusić tę modułowość . Z wieloma jednostkami tłumaczeniowymi masz doskonałą kontrolę nad interfejsami modułów za pomocą np. extern i static słów kluczowych.

Łącząc swój kod w jedną jednostkę tłumaczeniową, ominiesz wszelkie problemy z modułowością, ponieważ kompilator nie będzie Cię o nich ostrzegał. W dużym projekcie to w końcu spowoduje niezamierzone zależności rozprzestrzeniające się wokół. W końcu będziesz miał problem ze zmianą dowolnego modułu bez tworzenia globalnych efektów ubocznych w innych modułach.

Jeśli umieścisz wszystkie pliki w jednym miejscu, będziesz musiał zdefiniować to, czego potrzebujesz tylko raz, a nie we wszystkich plikach źródłowych.

To jest cel .h plików, więc można zdefiniować to, czego potrzebujesz raz i umieścić go wszędzie. Niektóre projekty mają nawet nagłówek everything.h, który zawiera każdy pojedynczy plik .h. Tak więc twój pro {[10] } może być również osiągnięty za pomocą oddzielnych plików .c.

Oznacza to, że nie muszę pisać pliku nagłówkowego dla każda funkcja którą tworzę [...]

I tak nie powinieneś pisać jednego pliku nagłówkowego dla każdej funkcji. Powinieneś mieć jeden plik nagłówkowy dla zestawu powiązanych funkcji. Więc twój con {[10] } też nie jest ważny.

Oznacza to, że nie muszę pisać pliku nagłówkowego dla każdej tworzonej funkcji (ponieważ są one już w głównym pliku źródłowym), a także oznacza, że nie muszę dołączać standardowych bibliotek do każdego tworzonego pliku. Dla mnie to świetny pomysł!

Plusy, które zauważyłeś, są w rzeczywistości powodem, dla którego czasami robi się to w mniejszej skali.

Może być jednak użyty do rozbicia jednostki tłumaczeniowej na mniejsze bity, które współdzielą dostęp do funkcji w sposób przypominający dostępność pakietu Javy.

Sposób osiągnięcia powyższego wymaga pewnej dyscypliny i pomocy preprocesora.

Na przykład, możesz podzielić jednostkę tłumaczenia na dwa pliki:

// a.c

static void utility() {
}

static void a_func() {
  utility();
}

// b.c

static void b_func() {
  utility();
}

Teraz dodajesz plik do swojej jednostki tłumaczeniowej:

// ab.c

static void utility();

#include "a.c"
#include "b.c"

A Twój system budowania też nie buduje a.c lub b.c, ale zamiast tego buduje tylko ab.o z ab.c.

Co ab.c osiąga?

Zawiera oba pliki do generowania pojedynczej jednostki tłumaczenia i zapewnia prototyp dla narzędzia. Aby Kod zarówno a.c, jak i b.c mógł go zobaczyć, niezależnie od kolejności, w jakiej są zawarte, i bez wymogu, aby funkcja była extern.