Odpowiedź

inline to sugestia dla kompilatora, aby zastąpić wywołanie funkcji jej ciałem (wstawienie kodu). Może to przyspieszyć wykonanie (brak kosztów związanych z wywołaniem), ale prowadzi do zwiększenia rozmiaru binarnego.

Składnia:

inline int square(int x) { return x * x; }

Kompilator ma prawo zignorować inline. Aby jednocześnie umożliwić widoczność i implementację funkcji w różnych plikach, używamy:

// header.h
inline int min(int a, int b) { return a < b ? a : b; }

Całe ciało funkcji musi być dostępne w każdym pliku, w którym wywoływana jest funkcja inline, więc zwykłym sposobem jest definiowanie funkcji w pliku nagłówkowym.

Jeśli zdefiniujesz funkcję inline tylko w jednym pliku .c, inne moduły nie będą mogły jej używać, co spowoduje błędy linkowania (undefined reference).

Pytanie z pułapką

Jaka jest różnica między takimi deklaracjami w pliku nagłówkowym?

inline int foo(int x) { return x + 1; }
static inline int bar(int x) { return x + 1; }

Odpowiedź:

• inline int foo(...) pozwala na posiadanie wielu słabych definicji (one definition rule). Jeśli z kilku plików .c włączony jest ten sam nagłówek, linker może zgłosić błąd wielokrotnego definiowania.
• static inline czyni funkcję wewnętrzną dla każdego modułu: każdy punkt połączenia otrzymuje swoją kopię, co eliminuje problemy na etapie linkowania. Jest to najbezpieczniejsze dla funkcji inline w plikach nagłówkowych.

Przykłady rzeczywistych błędów z powodu nieznajomości szczegółów tematu

---

Historia

W bibliotece funkcji matematycznych definiowano wiele pomocników inline w pliku .c. Przy próbie użycia ich z innych modułów pojawiały się błędy linkowania, ponieważ definicje były widoczne tylko w jednym pliku obiektowym.

---

Historia

Po przeniesieniu funkcji inline z pliku .c do nagłówka projekt zaczął się zwieszać na etapie linkowania: linker narzekał na wielokrotne definicje tej samej funkcji. Naprawiono to deklarując jako static inline w plikach nagłówkowych.

---

Historia

W optymalizacji wewnętrznego algorytmu używano inline dla "krytycznych" funkcji, oczekując przyspieszenia. Ale kompilator zignorował sugestię, a profiler pokazał, że koszty wywołań nie zmniejszyły się. Problem został rozwiązany dopiero po ręcznej analizie opcji optymalizacji kompilatora.