Значення файлу .inl у C ++

Які переваги мають декларації у файлі .inl? Коли мені потрібно використовувати те саме?

.inlфайли ніколи не є обов'язковими і не мають особливого значення для компілятора. Це лише спосіб структурування коду, який надає підказки людям, які можуть його прочитати.

Я використовую .inlфайли у двох випадках:

• Для визначення вбудованих функцій.
• Для визначення шаблонів функцій.

В обох випадках я поміщав оголошення функцій в заголовки, який включений іншими файлами, то я #includeна .inlфайл в нижній частині заголовка файлу.

Мені це подобається, оскільки він відділяє інтерфейс від реалізації та робить файл заголовка трохи легшим для читання. Якщо ви дбаєте про деталі реалізації, ви можете відкрити .inlфайл і прочитати його. Якщо ні, то не потрібно.

Нік Мейєр правий: компілятор не переймається розширенням файлу, який ви включаєте, тому такі речі, як ".h", ".hpp", ".hxx", ".hh", ".inl", ".inc" тощо - це звичайна умова, щоб зрозуміти, що файли повинні містити.

Найкращий приклад - файли заголовків STL, які не мають жодного розширення.

Зазвичай файли ".inl" містять вбудований код (звідси розширення ".inl").

Ці файли ".inl" - це необхідність, коли у вас є цикл залежності між кодом заголовка .

Наприклад:

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

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

І:

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

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

У вас немає ніякого способу компілювати його, включаючи використання прямої декларації.

Тоді рішення полягає в розбитті визначення та реалізації на два типи файлів заголовків:

• hpp для оголошення / визначення заголовка
• inl для реалізації заголовка

Який розбивається на наступний приклад:

// A.hpp

struct B ;

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

І:

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

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

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

І:

// B.hpp

struct A ;

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

І:

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

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

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

Таким чином, ви можете включити будь-який файл ".inl" у свій власний джерело, і він буде працювати.

Знову ж таки, імена суфіксів включених файлів насправді не важливі, а лише їх використання.

Оскільки ніхто інший цього не згадував:

Використання файлів .inl для зберігання вбудованих функцій може бути корисним для прискорення компіляції.

Якщо ви включаєте лише декларації (.h) там, де вам потрібні декларації, і включаєте лише вбудовані реалізації (.inl) там, де вони вам потрібні (тобто, ймовірно, лише у .cpp та інші .inl файли, а не .h's), вони можуть мати сприятливо впливає на залежність вашого заголовка.

Це може бути значним виграшем у великих проектах із багатьма взаємодіючими класами.

На мій досвід, .inl файли використовуються для визначення вбудованих функцій. Коли вони знаходяться у файлі .inl, файл можна включити до заголовка для отримання вбудованих функцій, а у .c-файл для отримання регулярних визначень функцій.

Таким чином, те саме джерело може легше працювати з компіляторами, які не мають вбудованих функцій підтримки, а також компіляторами, які це роблять.

Зазвичай вони використовуються з прямим кодом C, а не часто з кодом C ++, оскільки всі компілятори C ++ підтримують вбудовані функції.

Я вважаю, що це лише умова іменування для файлу "заголовка", що включає вбудований код. це так, що .h файли можуть містити визначення, а .inl файли містять вбудований код, необхідний для шаблонів.

Я не вірю, що в ньому є щось більше, ніж угода про іменування, щоб зрозуміти мету файлу