Napisałeś kod. To działa. Ale teraz chcesz użyć generatora rand() lub procedury bubble_sort w zupełnie innym projekcie. Kopiowanie i wklejanie jest leniwe. To także kruche podejście. Kiedy aktualizujesz jedną wersję, musisz przeszukać każdą kopię kodu.
Profesjonalne rozwiązanie? Utwórz bibliotekę.
W ekosystemie C biblioteka nie jest magiczną czarną skrzynką. To tylko dwa pliki, które pełnią różne role. Potrzebujesz pliku nagłówkowego (.h ) i pliku źródłowego (.c ). Plik nagłówkowy informuje resztę świata, jakie funkcje istnieją. Plik źródłowy wykonuje prawdziwą pracę.
Tworzenie interfejsu: util.h
Plik nagłówkowy działa jak kontrakt. Nie zawiera logiki. Zawiera obietnice. Stałe, typy i prototypy funkcji.
Utwórz plik o nazwie util.h.
Słowa kluczowe „extern” wykonują najcięższą pracę. Mówią kompilatorowi: „Nie szukaj tutaj implementacji. Znajdę ją później podczas łączenia”. Jeśli utkniesz na przestarzałym kompilatorze, który jest starszy niż współczesne standardy C, usuń opcje z bubble_sort. Stare kompilatory są bardzo wybredne.
Mechanizmy ukrywania: util.c
Teraz sam kod. Zapisz to jako util.c.
Zwróć uwagę na dyrektywę include. Używamy cudzysłowów („util.h”) zamiast nawiasów ostrych (
Oto subtelny punkt: rand_seed. Znajduje się w util.c. Nie jest w util.h. To informacja ukryta w działaniu. Kod korzystający z tej biblioteki może wywołać funkcję rand(), ale nie może uzyskać bezpośredniego dostępu do materiału siewnego. Państwo jest zamknięte. Aby uzyskać ścisłą kontrolę, możesz dodać słowo kluczowe static przed definicją zmiennej. To niezawodnie blokuje dostęp. Brak dostępu z zewnątrz. Kropka.
Użycie biblioteki: main.c
Teraz napisz program, który go użyje. Zapisz to jako main.c.
W skrócie? Tak. Odkurzacz? Niewątpliwie. Program główny nie przejmuje się sposobem, w jaki „rand()” generuje liczby. Ona tylko prosi o numer. W tym podziale tkwi cały sens.
Kompilacja i linkowanie
Jak mogę zamienić te pojedyncze pliki w działający plik wykonywalny? Wykonujesz trzyetapowy taniec.
Najpierw skompiluj kod źródłowy biblioteki do pliku obiektowego. Zakładając, że używasz systemu podobnego do UNIX z GCC:
,,bicie
gcc -c -g util.c
To generuje main.o. Znowu tylko kod maszynowy. Nadal nie ma logiki bibliotecznej.
Na koniec zwiąż je razem.
,,bicie
gcc -o main main.o util.o
“`
To polecenie pobiera oba pliki obiektowe i łączy je w jeden plik wykonywalny o nazwie main. Masz teraz kompletny program. Uruchom go z ./main (lub po prostu main, jeśli używasz Windows lub dodałeś go do swojej PATH).
To dużo kroków dla dwóch funkcji. Ale wyobraź sobie, że robisz to dla projektu zawierającego pięćdziesiąt plików. Każdy plik .c kompilujesz raz. Łączysz je ze sobą. Zmieniłeś funkcję w bibliotece? Skompiluj ponownie tylko ten plik. Zawiąż ponownie. Reszta pozostaje nietknięta.
Pliki Makefile automatyzują to
