Jak kompilator C/C++ znajduje definicje funkcji zadeklarowanych w plikach nagłówkowych?

Question

Witam,

ciekawi mnie, jak kompilator wie, gdzie są definicje funkcji zadeklarowanych w plikach nagłówkowych. Może znajduje pliki z nimi po nazwie, czy po dołączonych nagłówkach... nie wiem, więc pytanie zostawiam wtajemniczonym bardziej ode mnie.

Za każdą odpowiedź serdecznie dziękuję.

Answer 1

Nie wie.

Są dwa główne etapy budowania programu w C i C++: kompilacja i linkowanie.

Kompilacja zamienia "jednostki translacji" (czyli pliki .cpp po przejściu przez preprocesor) na pośrednie "pliki obiektowe" z rozszerzeniem .o. Do ich stworzenia wystarczą deklaracje funkcji z nagłówków. Taki plik obiektowy ma mnóstwo "placeholderów" typu "a teraz wywołaj funkcję moja_funkcja()".

Teoretycznie mógłbyś każdy plik .cpp skompilować niezależnie (bez żadnej wiedzy o innych plikach .cpp) osobną komendą i dopiero potem połączyć je w prawdziwy program.

Linker bierze wszystkie pliki obiektowe razem i łączy je w jeden plik wykonywalny. Tam gdzie wcześniej było "wywołaj funkcję moja_funkcja()", to linker szuka skompilowanej funkcji o tej deklaracji, umieszcza ją gdzieś w pliku wynikowym, a skoro wie gdzie ona się teraz znajduje to może ten placeholder zamienić na "wywołaj funkcję pod adresem 0x2351234".

Comments

OK, ale zostaje kwestia tego "szukania". Jak on to robi? Wyszukuje katalogi, gdzie znajduje się kod, czy co?

---

Podstawowe biblioteki wie gdzie szukać ale inne trzeba ręcznie wskazać jako parametr przy kompilacji.

W przypadku korzystania z IDE i pakietów dodatkowych bibliotek może to być zautomatyzowane ale dawniej trzeba było przy każdej kompilacji wszystko podawać jako argumenty. Dla ułatwienia sprawy stworzono więc program Make i pliki Makefile.

Niektóre IDE do tej pory najpierw generują plik Makefile a potem wywołują program Make.

---

Wie bo zostało mu to przekazane w argumentach.

Jak tworzysz na przykład projekt w Code::Blocksie, to on w tych swoich plikach projektu zapisuje jakie pliki są jego częścią i wie które z nich dać kompilatorowi.

Na przykład gdybyś miał projekt z dwoma plikami, main.cpp i inny.cpp, przy budowaniu projektu C::B by wykonał (w uproszczeniu) takie komendy:

# kompilacja plikow .cpp do plikow posrednich
g++ main.cpp -c -o main.o
g++ inny.cpp -c -o inny.o
# linkowanie do pliku wykonywalnego
# (tutaj g++ tak naprawde tylko wywoluje prawdziwy linker: ld)
g++ main.o inny.o -o main.exe

 

---

Gdybyś w programie wykorzystał bibliotekę math to potem musiał być w komendach podanych przez adrian17 dodać parametr -lm aby dolinkowało wcześniej skompilowaną bibliotekę math.

A jak by ten plik nie był w standardowym miejscu to trzeba by było dodać też informacje o katalogu - jeśli dobrze pamiętam (duże i) -I katalog_docelowy

---

No tak, rzeczywiście. Po prostu testy robiłem na projekcie, który już miał dołączone pliki z definicjami funkcji, a ja je tylko odłączałem od projektu i program nadal się kompilował (zapewne IDE nadal wysyłało informacje o tych plikach kompilatorowi, choć odpowiednie pliki nie znajdowały się w projekcie). Później, gdy zrobiłem testy w nowym projekcie, to rzeczywiście, dopiero, gdy dodałem odpowiednie pliki do projektu, program się skompilował.

Answer 2

Nie jestem projektantem kompilatora, ale obserwując efekty jego działania (tak, tak - błędy to są też efekty! ;) sądzę, że napotykając na deklarację funkcji, zapisuje ją sobie w jakimś miejscu przeznaczonym do tego celu, z ewentualnym pustym polem na adres (czy może raczej: offset?), do wypełnienia "później".

Jeśli piszesz program w IDE, to dodajesz pliki do projektu źródłowe (z definicjami), prawda?
Jeśli kompilator natrafia na definicję (w Twoim pliku), to do wcześniej przygotowanej deklaracji może dorzucić adres ciała funkcji.
Jeśli takiej definicji w Twoich plikach nie znajdzie, to po prostu zostawi pole adresu puste, obarczając Ciebie zadaniem dostarczenia linkerowi (który pracuje po kompilatorze) odpowiednich skompilowanych plików.
A jeśli linker takich nie dostanie, to Ty dostaniesz... komunikat linkera: "undefined reference to...". :)

Oczywiście to tylko moje domysły. :)

Comments

Oho, czyli niektóre domysły były poprawne. :)