Significado de um arquivo .inl em C ++

Quais são as vantagens de ter declarações em um arquivo .inl? Quando devo usar o mesmo?

.inlos arquivos nunca são obrigatórios e não têm nenhum significado especial para o compilador. É apenas uma forma de estruturar seu código que fornece uma dica para os humanos que podem lê-lo.

Eu uso .inlarquivos em dois casos:

• Para definições de funções embutidas.
• Para definições de modelos de funções.

Em ambos os casos, coloco as declarações das funções em um arquivo de cabeçalho, que é incluído por outros arquivos, e então #includeo .inlarquivo na parte inferior do arquivo de cabeçalho.

Eu gosto porque separa a interface da implementação e torna o arquivo de cabeçalho um pouco mais fácil de ler. Se você se preocupa com os detalhes da implementação, pode abrir o .inlarquivo e lê-lo. Se não, você não precisa.

Nick Meyer está certo: o compilador não se preocupa com a extensão do arquivo que você está incluindo, então coisas como ".h", ".hpp", ".hxx", ".hh", ".inl", ".inc", etc. são uma convenção simples, para deixar claro o que os arquivos devem conter.

O melhor exemplo são os arquivos de cabeçalho STL que não possuem qualquer extensão.

Normalmente, os arquivos ".inl" contêm código embutido (daí a extensão ".inl").

Esses arquivos arquivos ".inl" são uma necessidade quando você tem um ciclo de dependência entre o código do cabeçalho .

Por exemplo:

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

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

E:

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

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

Não há como fazer com que seja compilado, incluindo o uso de declaração de encaminhamento.

A solução é dividir a definição e a implementação em dois tipos de arquivos de cabeçalho:

• hpp para declaração / definição de cabeçalho
• inl para implementação de cabeçalho

Que se divide no seguinte exemplo:

// A.hpp

struct B ;

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

E:

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

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

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

E:

// B.hpp

struct A ;

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

E:

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

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

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

Desta forma, você pode incluir qualquer arquivo ".inl" que você precisa em sua própria fonte, e ele funcionará.

Novamente, os nomes de sufixo dos arquivos incluídos não são realmente importantes, apenas seus usos.

Já que ninguém mais mencionou:

O uso de arquivos .inl para armazenar suas funções embutidas pode ser útil para acelerar as compilações.

Se você incluir apenas as declarações (.h) onde precisa de declarações, e incluir apenas implementações inline (.inl) onde você precisa (ou seja, provavelmente apenas em .cpp e outros arquivos .inl, não .h's), ele pode ter um efeito benéfico em suas dependências de cabeçalho.

Isso pode ser uma vitória significativa em projetos maiores com muitas classes interagindo.

Na minha experiência, os arquivos .inl são usados ​​para definir funções embutidas. Quando eles estão em um arquivo .inl, o arquivo pode ser incluído em um cabeçalho para obter funções embutidas e em um arquivo .c para obter definições de funções regulares.

Dessa forma, a mesma fonte pode funcionar mais facilmente com compiladores que não têm suporte de função embutida, bem como compiladores que têm.

Eles geralmente são usados ​​com código C direto, nem sempre com código C ++, pois todos os compiladores C ++ suportam funções embutidas.

Acredito que seja apenas uma convenção de nomenclatura para um arquivo de "cabeçalho" que inclui código embutido. é para que os arquivos .h possam conter definições e os arquivos .inl contenham código embutido que é necessário para os modelos.

Não acredito que haja algo mais nisso do que uma convenção de nomenclatura para deixar claro o propósito do arquivo