Significato di un file .inl in C ++

Quali sono i vantaggi di avere dichiarazioni in un file .inl? Quando dovrei usare lo stesso?

.inli file non sono mai obbligatori e non hanno alcun significato speciale per il compilatore. È solo un modo per strutturare il codice che fornisce un suggerimento agli umani che potrebbero leggerlo.

Uso i .inlfile in due casi:

• Per le definizioni delle funzioni inline.
• Per le definizioni dei modelli di funzione.

In entrambi i casi, metto le dichiarazioni delle funzioni in un file di intestazione, che è incluso da altri file, quindi ho #includeil .inlfile in fondo al file di intestazione.

Mi piace perché separa l'interfaccia dall'implementazione e rende il file di intestazione un po 'più facile da leggere. Se ti interessano i dettagli di implementazione, puoi aprire il .inlfile e leggerlo. Se non lo fai, non devi.

Nick Meyer ha ragione: al compilatore non interessa l'estensione del file che stai includendo, quindi cose come ".h", ".hpp", ".hxx", ".hh", ".inl", ".inc", ecc. sono una semplice convenzione, per chiarire cosa dovrebbero contenere i file.

Il miglior esempio sono i file di intestazione STL che non hanno alcuna estensione.

Di solito, i file ".inl" contengono codice inline (da cui l'estensione ".inl").

Quei file ".inl" sono una necessità quando si ha un ciclo di dipendenza tra il codice dell'intestazione .

Per esempio:

// 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() ;
    }
} ;

Non c'è modo di compilarlo, incluso l'uso della dichiarazione in avanti.

La soluzione è quindi suddividere la definizione e l'implementazione in due tipi di file di intestazione:

• hpp per la dichiarazione / definizione dell'intestazione
• inl per l'implementazione dell'intestazione

Che si scompone nel seguente esempio:

// 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() ;
}

In questo modo, puoi includere qualsiasi file ".inl" di cui hai bisogno nel tuo codice sorgente e funzionerà.

Ancora una volta, i nomi dei suffissi dei file inclusi non sono molto importanti, solo il loro utilizzo.

Poiché nessun altro lo ha menzionato:

L'uso di file .inl per memorizzare le funzioni inline può essere utile per velocizzare le compilazioni.

Se includi solo le dichiarazioni (.h) in cui hai bisogno di dichiarazioni e includi solo implementazioni inline (.inl) dove ne hai bisogno (cioè probabilmente solo in .cpp e altri file .inl, non .h), può avere un effetto benefico sulle dipendenze dell'intestazione.

Questa può essere una vittoria significativa su progetti più grandi con molte classi interagenti.

Nella mia esperienza, i file .inl vengono utilizzati per definire le funzioni inline. Quando si trovano in un file .inl, il file può essere incluso in un'intestazione per ottenere funzioni inline e in un file .c per ottenere definizioni di funzioni regolari.

In questo modo la stessa sorgente può lavorare più facilmente con i compilatori che non hanno il supporto per le funzioni inline così come i compilatori che lo hanno.

Di solito vengono utilizzati con codice C semplice, non spesso con codice C ++ poiché tutti i compilatori C ++ supportano le funzioni inline.

Credo che sia solo una convenzione di denominazione per un file di "intestazione" che include codice in linea. è così che i file .h possono contenere definizioni e i file .inl contengono codice inline necessario per i modelli.

Non credo ci sia altro che una convenzione di denominazione per rendere chiaro lo scopo del file