Значение файла .inl в С++

Ответ 1

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

Я использую файлы .inl в двух случаях:

• Для определения встроенных функций.
• Для определения шаблонов функций.

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

Мне это нравится, потому что он отделяет интерфейс от реализации и упрощает чтение заголовочного файла. Если вы заботитесь о деталях реализации, вы можете открыть файл .inl и прочитать его. Если вы этого не сделаете, вам не нужно.

Ответ 2

Nick Meyer прав: компилятор не заботится о расширении файла, который вы включаете, поэтому такие вещи, как ".h", ".hpp".hxx ",".hh ",".inl ",".inc" и т.д. - это простое соглашение, чтобы дать понять, какие файлы должны содержать.

Лучшим примером являются файлы заголовков STL, которые не имеют расширения.

Обычно файлы ".inl" содержат код inline (следовательно, расширение ".inl" ).

Эти файлы ".inl" необходимы, если у вас есть цикл зависимостей между кодом header.

Например:

// 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" файл, который вам нужен в вашем собственном источнике, и он будет работать.

Опять же, имена суффиксов включенных файлов не очень важны, только их использование.

Ответ 3

Поскольку никто еще не упомянул об этом:

Использование .INL файлов для хранения ваших встроенных функций может быть полезно для ускорения компиляции.

Если вы включаете объявления (.h), где вам нужны декларации, и включайте только встроенные реализации (.inl), где они вам нужны (т.е. вероятно, только в .cpp и других .INL файлах, а не .h), это может оказать положительное влияние на зависимости вашего заголовка.

Это может быть значительная победа в крупных проектах со многими взаимодействующими классами.

Ответ 4

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

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

Обычно они используются с прямым кодом C, а не часто с кодом С++, поскольку все компиляторы С++ поддерживают встроенные функции.

Ответ 5

Я считаю, что просто соглашение об именах для файла заголовка включает встроенный код. это так, что файлы .h могут содержать определения, а файлы .inl содержат встроенный код, необходимый для шаблонов.

Я не верю, что в этом есть что-то большее, чем соглашение об именах, чтобы очистить файл