Importancia de un archivo .inl en C ++

¿Cuáles son las ventajas de tener declaraciones en un archivo .inl? ¿Cuándo debería usar el mismo?

.inlLos archivos nunca son obligatorios y no tienen un significado especial para el compilador. Es solo una forma de estructurar su código que proporciona una pista a los humanos que podrían leerlo.

Utilizo .inlarchivos en dos casos:

• Para obtener definiciones de funciones en línea.
• Para obtener definiciones de plantillas de funciones.

En ambos casos, puse las declaraciones de las funciones en un fichero de cabecera, que se incluye por otros archivos, entonces #includela.inl archivo en la parte inferior del archivo de cabecera.

Me gusta porque separa la interfaz de la implementación y hace que el archivo de encabezado sea un poco más fácil de leer. Si le interesan los detalles de implementación, puede abrir el .inlarchivo y leerlo. Si no lo hace, no es necesario.

Nick Meyer tiene razón: al compilador no le importa la extensión del archivo que estás incluyendo, así que cosas como ".h", ".hpp", ".hxx", ".hh", ".inl", ".inc", etc. son una convención simple, para dejar claro lo que se supone que contienen los archivos.

El mejor ejemplo son los archivos de encabezado STL que no tienen extensión alguna.

Por lo general, los archivos ".inl" contienen código en línea (de ahí la extensión ".inl").

Esos archivos ".inl" son una necesidad cuando tiene un ciclo de dependencia entre el código de encabezado .

Por ejemplo:

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

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

Y:

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

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

No hay forma de que lo compile, incluido el uso de la declaración de avance.

Entonces, la solución es dividir la definición y la implementación en dos tipos de archivos de encabezado:

• hpp para declaración / definición de encabezado
• inl para la implementación del encabezado

Que se desglosa en el siguiente ejemplo:

// A.hpp

struct B ;

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

Y:

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

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

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

Y:

// B.hpp

struct A ;

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

Y:

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

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

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

De esta manera, puede incluir cualquier archivo ".inl" que necesite en su propia fuente, y funcionará.

Nuevamente, los nombres de los sufijos de los archivos incluidos no son realmente importantes, solo sus usos.

Como nadie más lo ha mencionado:

El uso de archivos .inl para almacenar sus funciones en línea puede resultar útil para acelerar las compilaciones.

Si solo incluye las declaraciones (.h) donde necesita declaraciones, y solo incluye implementaciones en línea (.inl) donde las necesita (es decir, probablemente solo en .cpp y otros archivos .inl, no .h), puede tener un efecto beneficioso en sus dependencias de encabezado.

Esto puede ser una ventaja significativa en proyectos más grandes con muchas clases interactivas.

En mi experiencia, los archivos .inl se utilizan para definir funciones en línea. Cuando están en un archivo .inl, el archivo se puede incluir en un encabezado para obtener funciones en línea y en un archivo .c para obtener definiciones de funciones regulares.

De esta manera, la misma fuente puede trabajar más fácilmente con compiladores que no tienen soporte de funciones en línea, así como con compiladores que sí lo tienen.

Por lo general, se usan con código C directo, no a menudo con código C ++, ya que todos los compiladores de C ++ admiten funciones en línea.

Creo que es solo una convención de nomenclatura para un archivo de "encabezado" que incluye código en línea. es para que los archivos .h puedan contener definiciones y los archivos .inl contengan código en línea que es necesario para las plantillas.

No creo que haya nada más que una convención de nomenclatura para aclarar el propósito del archivo