Jak działają pliki nagłówkowe i źródłowe w C?

Język C nie ma pojęcia o plikach źródłowych i plikach nagłówkowych (podobnie jak kompilator). Jest to tylko konwencja; pamiętaj, że plik nagłówkowy jest zawsze #included w pliku źródłowym; preprocesor dosłownie po prostu kopiuje-wkleja zawartość, zanim rozpocznie się właściwa kompilacja.

Twój przykład powinien skompilować (bez względu na głupie błędy składniowe). Na przykład używając GCC, możesz najpierw wykonać:

gcc -c -o source.o source.c
gcc -c -o main.o main.c

Kompiluje każdy plik źródłowy osobno, tworzenie niezależnych plików obiektowych. Na tym etapie returnSeven() nie został rozwiązany wewnątrz main.c; kompilator tylko oznaczył plik obiektowy w sposób, który stwierdza, że musi zostać rozwiązany w przyszłości. Więc na tym etapie nie jest problemem, że main.c nie widzi definicji z returnSeven(). (Uwaga: jest to odmienne od faktu, że main.c musi być w stanie zobaczyć deklarację z returnSeven() w celu kompilacji; musi wiedzieć, że rzeczywiście jest to funkcja i jaki jest jej prototyp. Że dlatego musisz #include "source.h" W main.c.)

Potem robisz:

gcc -o my_prog source.o main.o

To łączy dwa pliki obiektowe razem w wykonywalny plik binarny i wykonuje rozdzielczość symboli. W naszym przykładzie jest to możliwe, ponieważ main.o wymaga returnSeven(), a to jest ujawnione przez source.o. W przypadkach, gdy wszystko się nie zgadza, spowodowałby błąd łącznika.

Nie ma nic magicznego w kompilacji. Ani automatyczne!

Pliki nagłówkowe w zasadzie dostarczają informacji kompilatorowi, prawie nigdy nie kodują.
Sama ta informacja zwykle nie wystarcza do stworzenia pełnego programu.

Rozważ program "hello world" (z prostszą funkcją puts):

#include <stdio.h>
int main(void) {
    puts("Hello, World!");
    return 0;
}

Bez nagłówka kompilator nie wie, jak radzić sobie z puts() (nie jest to słowo kluczowe C). Nagłówek pozwala kompilatorowi wiedzieć, jak zarządzać argumentami i zwracana wartość.

Sposób działania funkcji nie jest jednak nigdzie określony w tym prostym kodzie. Ktoś inny napisał kod puts() i włączył skompilowany kod do biblioteki. Kod w tej bibliotece jest dołączany do skompilowanego kodu źródłowego w ramach procesu kompilacji.

Teraz Uznaj, że chciałeś mieć własną wersję puts()

int main(void) {
    myputs("Hello, World!");
    return 0;
}

Kompilowanie tylko tego kodu powoduje błąd, ponieważ kompilator nie ma informacji o funkcji. Ty może dostarczyć te informacje

int myputs(const char *line);
int main(void) {
    myputs("Hello, World!");
    return 0;
}

A kod teraz kompiluje - - - ale nie linkuje, ie nie tworzy pliku wykonywalnego, ponieważ nie ma kodu dla myputs(). Więc piszesz kod dla myputs() w pliku o nazwie " myputs.c "

#include <stdio.h>
int myputs(const char *line) {
    while (*line) putchar(*line++);
    return 0;
}

I musisz pamiętać, aby skompilować zarówno swój pierwszy plik źródłowy, jak i " myputs.c " razem.

Po chwili twoje " myputs.c " plik rozszerzył się do ręki pełnej funkcji i trzeba zawierać informacje o wszystkich funkcje (ich prototypy) w plikach źródłowych, które chcą z nich korzystać.
Wygodniej jest zapisać wszystkie prototypy w jednym pliku i #include tego pliku. Dzięki włączeniu nie ryzykujesz popełnienia błędu podczas pisania prototypu.

Nadal musisz skompilować i połączyć wszystkie pliki kodu razem.

Gdy rosną jeszcze bardziej, umieszczasz cały skompilowany kod w bibliotece ... i to już inna historia:)

Pliki nagłówkowe są używane do oddzielania deklaracji interfejsu, które odpowiadają implementacjom w plikach źródłowych. Są maltretowani w inny sposób, ale jest to powszechny przypadek. To nie jest dla kompilatora, tylko dla ludzi piszących kod.

Większość kompilatorów nie widzi tych dwóch plików osobno, są one połączone przez preprocesor.

Sam kompilator nie ma specyficznej "wiedzy" o relacjach między plikami źródłowymi a plikami nagłówkowymi. Te typy relacji są zazwyczaj definiowane przez pliki projektu (np. makefile, solution, itp.).

Podany przykład wygląda tak, jakby skompilował się poprawnie. Trzeba by skompilować oba pliki źródłowe, a następnie linker będzie potrzebował obu plików obiektowych do wytworzenia pliku wykonywalnego.