Znaczenie pliku .inl w C ++

Jakie są zalety posiadania deklaracji w pliku .inl? Kiedy powinienem użyć tego samego?

.inlpliki nigdy nie są obowiązkowe i nie mają specjalnego znaczenia dla kompilatora. Jest to tylko sposób na uporządkowanie kodu, który jest wskazówką dla ludzi, którzy mogą go przeczytać.

Używam .inlplików w dwóch przypadkach:

• Definicje funkcji wbudowanych.
• Definicje szablonów funkcji.

W obu przypadkach deklaracje funkcji umieszczam w pliku nagłówkowym, który jest dołączany do innych plików, a następnie #includeumieszczam .inlplik na dole pliku nagłówkowego.

Podoba mi się, ponieważ oddziela interfejs od implementacji i sprawia, że ​​plik nagłówkowy jest trochę łatwiejszy do odczytania. Jeśli zależy Ci na szczegółach implementacji, możesz otworzyć .inlplik i przeczytać. Jeśli nie, nie musisz.

Nick Meyer ma rację: kompilator nie dba o rozszerzenie dołączanego pliku, więc takie rzeczy jak „.h”, „.hpp”, „.hxx”, „.hh”, „.inl”, „.inc” itp. są prostą konwencją, aby było jasne, co mają zawierać pliki.

Najlepszym przykładem są pliki nagłówkowe STL, które nie mają żadnego rozszerzenia.

Zwykle pliki „.inl” zawierają wbudowany kod (stąd rozszerzenie „.inl”).

Te pliki „.inl” są niezbędne, gdy istnieje cykl zależności między kodem nagłówka .

Na przykład:

// A.hpp
struct A
{
    void doSomethingElse()
    {
       // Etc.
    }

    void doSomething(B & b)
    {
       b.doSomethingElse() ;
    }
} ;

I:

// B.hpp
struct B
{
    void doSomethingElse()
    {
       // Etc.
    }

    void doSomething(A & a)
    {
       a.doSomethingElse() ;
    }
} ;

Nie ma możliwości, abyś go skompilował, w tym używając deklaracji do przodu.

Rozwiązaniem jest wtedy rozbicie definicji i implementacji na dwa rodzaje plików nagłówkowych:

• hpp do deklaracji / definicji nagłówka
• inl do implementacji nagłówka

Który dzieli się na następujący przykład:

// A.hpp

struct B ;

struct A
{
    void doSomethingElse() ;
    void doSomething(B & b) ;
} ;

I:

// A.inl
#include <A.hpp>
#include <B.hpp>

inline void A::doSomethingElse()
{
   // Etc.
}

inline void A::doSomething(B & b)
{
   b.doSomethingElse() ;
}

I:

// B.hpp

struct A ;

struct B
{
    void doSomethingElse() ;
    void doSomething(A & a) ;
} ;

I:

// B.INL
#include <B.hpp>
#include <A.hpp>

inline void B::doSomethingElse()
{
   // Etc.
}

inline void B::doSomething(A & a)
{
   a.doSomethingElse() ;
}

W ten sposób możesz dołączyć dowolny plik „.inl” do swojego własnego źródła i będzie działać.

Ponownie, nazwy sufiksów dołączonych plików nie są tak naprawdę ważne, tylko ich zastosowania.

Ponieważ nikt inny o tym nie wspomniał:

Użycie plików .inl do przechowywania funkcji wbudowanych może być przydatne do przyspieszenia kompilacji.

Jeśli dołączysz tylko deklaracje (.h) tam, gdzie potrzebujesz deklaracji, i włączysz tylko implementacje wbudowane (.inl) tam, gdzie ich potrzebujesz (tj. Prawdopodobnie tylko w .cpp i innych plikach .inl, a nie .h), może mieć korzystny wpływ na zależności nagłówka.

Może to być znacząca wygrana w przypadku większych projektów z wieloma interaktywnymi klasami.

Z mojego doświadczenia wynika, że ​​pliki .inl służą do definiowania funkcji wbudowanych. Gdy znajdują się w pliku .inl, plik można dołączyć do nagłówka, aby uzyskać funkcje wbudowane, oraz do pliku .c, aby uzyskać zwykłe definicje funkcji.

W ten sposób to samo źródło może łatwiej współpracować z kompilatorami, które nie mają obsługi funkcji wbudowanych, jak również kompilatorami, które to robią.

Zwykle są używane z prostym kodem C, nie często z kodem C ++, ponieważ wszystkie kompilatory C ++ obsługują funkcje wbudowane.

Uważam, że jest to po prostu konwencja nazewnictwa dla pliku „nagłówkowego” zawierającego kod wbudowany. jest tak, że pliki .h mogą zawierać definicje, a pliki .inl zawierają wbudowany kod, który jest niezbędny dla szablonów.

Nie wierzę, że jest w tym coś więcej niż konwencja nazewnictwa, aby wyjaśnić cel pliku