Importance d'un fichier .inl en C ++

Quels sont les avantages d'avoir des déclarations dans un fichier .inl? Quand aurais-je besoin d'utiliser le même?

.inlles fichiers ne sont jamais obligatoires et n'ont aucune signification particulière pour le compilateur. C'est juste une façon de structurer votre code qui fournit un indice aux humains qui pourraient le lire.

J'utilise des .inlfichiers dans deux cas:

• Pour les définitions des fonctions en ligne.
• Pour les définitions des modèles de fonctions.

Dans les deux cas, je mets les déclarations des fonctions dans un fichier d'en-tête, qui est inclus par d'autres fichiers, puis je #includele .inlfichier en bas du fichier d'en-tête.

Je l'aime car il sépare l'interface de l'implémentation et rend le fichier d'en-tête un peu plus facile à lire. Si vous vous souciez des détails de l'implémentation, vous pouvez ouvrir le .inlfichier et le lire. Sinon, vous n'êtes pas obligé.

Nick Meyer a raison: le compilateur ne se soucie pas de l'extension du fichier que vous incluez, donc des choses comme ".h", ".hpp", ".hxx", ".hh", ".inl", ".inc", etc. sont une convention simple, pour préciser ce que les fichiers sont censés contenir.

Le meilleur exemple est les fichiers d'en-tête STL qui n'ont aucune extension.

Habituellement, les fichiers ".inl" contiennent du code en ligne (d'où l'extension ".inl").

Ces fichiers ".inl" sont une nécessité lorsque vous avez un cycle de dépendance entre le code d'en- tête .

Par exemple:

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

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

Et:

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

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

Il n'y a aucun moyen que vous le fassiez compiler, y compris en utilisant la déclaration forward.

La solution est alors de décomposer la définition et l'implémentation en deux types de fichiers d'en-tête:

• hpp pour la déclaration / définition d'en-tête
• inl pour l'implémentation de l'en-tête

Ce qui se décompose en l'exemple suivant:

// A.hpp

struct B ;

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

Et:

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

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

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

Et:

// B.hpp

struct A ;

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

Et:

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

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

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

De cette façon, vous pouvez inclure le fichier ".inl" dont vous avez besoin dans votre propre source, et cela fonctionnera.

Encore une fois, les noms de suffixe des fichiers inclus ne sont pas vraiment importants, seulement leurs utilisations.

Puisque personne d'autre ne l'a mentionné:

L'utilisation de fichiers .inl pour stocker vos fonctions en ligne peut être utile pour accélérer les compilations.

Si vous n'incluez que les déclarations (.h) là où vous avez besoin de déclarations, et n'incluez que les implémentations en ligne (.inl) là où vous en avez besoin (c'est-à-dire probablement uniquement dans .cpp et autres fichiers .inl, pas dans .h), il peut avoir un effet bénéfique sur vos dépendances d'en-tête.

Cela peut être une victoire significative sur des projets plus importants avec de nombreuses classes interactives.

D'après mon expérience, les fichiers .inl sont utilisés pour définir des fonctions en ligne. Lorsqu'ils sont dans un fichier .inl, le fichier peut être inclus dans un en-tête pour obtenir des fonctions en ligne et dans un fichier .c pour obtenir des définitions de fonctions régulières.

De cette façon, la même source peut plus facilement fonctionner avec des compilateurs qui n'ont pas de support de fonction en ligne ainsi que des compilateurs qui le font.

Ils sont généralement utilisés avec du code C simple, pas souvent avec du code C ++ car tous les compilateurs C ++ prennent en charge les fonctions en ligne.

Je crois que c'est juste une convention de dénomination pour un fichier "en-tête" comprenant du code en ligne. c'est pour que les fichiers .h puissent contenir des définitions et les fichiers .inl contiennent du code en ligne qui est nécessaire pour les modèles.

Je ne pense pas qu'il y ait autre chose qu'une convention de dénomination pour clarifier l'objectif du fichier