FAQ C++Consultez toutes les FAQ

Quand le compilateur �value l'appel d'une fonction inline, le code complet de cette fonction est ins�r� dans le code de l'appelant (c'est le m�me principe que ce qui se passe avec un #define). Cela peut, parmi beaucoup d'autres choses, am�liorer les performances, �tant donn� que l'optimiseur peut int�grer directement le code appel�, voire optimiser le code appel� en fonction du code appelant.

Il y a plusieurs fa�ons d'indiquer qu'une fonction est inline, certaines impliquant le mot-cl� inline, d'autres non. Peu importe comment une fonction est d�clar�e inline, c'est une demande que le compilateur est autoris� � ignorer : il peut en �valuer certaines, toutes ou m�me aucune. (Ne soyez pas d�courag�s si cela semble d�sesp�r�ment vague. La flexibilit� de ce qui pr�c�de est un avantage important : le compilateur peut g�rer de grosses fonctions diff�remment des petites, de plus, cela permet au compilateur de g�n�rer du code facile � d�boguer si vous sp�cifiez les bonnes options de compilation.)

Supposons l'appel suivant � une fonction g() :

1
2
3
4
5
6
7
8
9
void f() 
 { 
   int x = /*...*/; 
   int y = /*...*/; 
   int z = /*...*/; 
   // ...code qui utilise x, y et z... 
   g(x, y, z); 
   // ...plus de code qui utilise x, y et z... 
 }

1
2
3
4
void g(int x, int y, int z) 
 { 
   // ...code qui utilise x, y et z... 
 }

Cela d�pend.

Il n'y a pas de r�ponse simple. Les fonctions inline peuvent rendre le code plus rapide, mais elles peuvent aussi le rendre plus lent. Elles peuvent rendre le code plus gros ou le rendre plus petit. Elles peuvent ralentir consid�rablement le programme ou le rendre plus performant. Elles peuvent aussi n'avoir aucun impact sur la rapidit� du code.

Les fonctions inline peuvent rendre le code plus rapide Comme vu pr�c�demment, l'int�gration du code peut supprimer une poign�e d'instructions inutiles, ce qui peut rendre le code plus rapide.

Les fonctions inline peuvent rendre le code plus lent Un exc�s de fonctions inline peut rendre le code 'indigeste', ce qui peut provoquer un exc�s d'acc�s � la m�moire virtuelle sur certains syst�mes. En d'autres mots, si la taille de l'ex�cutable est trop importante, le syst�me risque de passer beaucoup de temps � faire de la pagination sur disque pour acc�der � la suite du code.

Les fonctions inline peuvent rendre le code plus gros C'est la notion de code 'indigeste', d�crite ci-dessus. Par exemple, si un programme a 100 fonctions inline qui augmenteront � chaque fois la taille de l'ex�cutable de 100 bytes et qui sont appel�es 100 fois chacune, l'augmentation de taille de l'ex�cutable sera proche de 1 MB. Est-ce que ce Mo posera probl�me ? Qui sait, mais ce Mo risque d'�tre celui qui fera faire de la pagination au syst�me et donc le ralentir.

Les fonctions inline peuvent rendre le code plus petit Les compilateurs g�n�rent souvent plus de code pour empiler / d�sempiler les param�tres que l'inclusion du code ne ferait. C'est ce qui arrive avec de tr�s petites fonctions, et cela peut m�me arriver avec de grosses fonctions quand l'optimiseur arrive � supprimer le code redondant via l'inclusion du code - l'optimiseur peut donc transformer de grosses fonctions en petites.

Les fonctions inline peuvent augmenter la pagination Le code g�n�r� peut devenir tr�s gros, ce qui risque de causer un ralentissement consid�rable.

Les fonctions inline peuvent r�duire la pagination Le nombre de pages qui doivent se trouver en m�moire au m�me moment peut se r�duire, alors que la taille de l'ex�cutable augmente. Quand f() appelle g(), le code peut tr�s bien se trouver dans deux pages diff�rentes, alors que lorsque le compilateur inclut le code de g() dans f(), le code a plus de probabilit� de se trouver dans la m�me page.

Les fonctions inline peuvent n'avoir aucune influence sur les performances Les performances ne sont pas li�es qu'au CPU. Par contre, les entr�es/sorties, les acc�s aux bases de donn�es, l'acc�s au r�seau peuvent repr�senter un s�rieux goulot d'�tranglement. � moins que votre CPU ne soit utilis� � 100�% la plupart du temps, l'utilisation des fonctions inline n'am�liorera pas les performances g�n�rales du syst�me (et m�me si le goulot d'�tranglement se situe au niveau du CPU, les fonctions inline ne seront utiles que dans le code posant probl�me, ce qui repr�sente souvent de tr�s petits morceaux de code).

Il n'y a pas de r�ponse simple : vous devez essayer et voir ce qui est le mieux. Ne vous limitez pas � des r�ponses simplistes telles que � Ne jamais utiliser les fonctions inline � ou � Toujours utiliser les fonctions inline � ou � N'utiliser les fonctions inline que si le code fait moins de . lignes de code �. Ces r�gles arbitraires sont peut-�tre faciles � �crire, mais les r�sultats sont plus que d�cevants.

En C pur, vous pouvez r�aliser des � structs (structures) encapsul�es � en mettant un void * dans un struct, o� le void * pointe sur les vraies donn�es qui sont inconnues aux utilisateurs du struct. Ainsi ces m�me utilisateurs du struct ne peuvent pas interpr�ter les donn�es point�es par void *, mais les fonctions d'acc�s peuvent elles convertir du void * vers le type de donn�es cach�. Ce qui donne une forme de l'encapsulation.

Malheureusement ceci impose de renoncer � la s�ret� de type, et impose �galement un appel de fonction pour acc�der m�me aux zones insignifiantes de la structure (si vous permettiez l'acc�s direct au champs de la structure, chacun pourrait acc�der directement � toute la structure puisqu'il conna�trait n�cessairement les donn�es point�es par void *, et il deviendrait difficile de changer la structure de donn�es sous-jacente).

Le temps d'appel de fonction est court, mais il s'ajoute � chaque appel. Les classes C++ permettent � ces appels de fonction d'�tre ins�r�s inline. Ceci vous laisse la s�ret� de l'encapsulation avec en plus la vitesse des acc�s directs. En outre, les types des param�tres de ces fonctions inline sont contr�l�s par le compilateur, ce qui est une am�lioration par rapport aux macros #define du C.

Parce que les #define sont mauvais. Mais parfois il faut les utiliser.

Contrairement aux #define, les fonctions inline �vitent des erreurs tr�s difficiles � tracer, �tant donn� que les fonctions inline �valuent toujours chaque argument une et une seule fois. En d'autres mots, l'invocation d'une fonction inline est s�mantiquement identique � l'invocation d'une fonction classique, avec la seule diff�rence de la rapidit�.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Macro qui renvoie la valeur absolue de i 
#define unsafe(i)  \ 
         ( (i) >= 0 ? (i) : -(i) ) 
  
// Fonction inline qui renvoie la valeur absolue de i 
inline 
int safe(int i) 
{ 
    return i >= 0 ? i : -i; 
} 
  
int f(); 
  
void userCode(int x) 
{ 
    int ans; 
  
    ans = unsafe(x++);   // Erreur ! x est incr�ment� deux fois 
    ans = unsafe(f());   // Danger ! f() est appel� deux fois 
  
    ans = safe(x++);     // Correct ! x est incr�ment� une seule fois 
    ans = safe(f());     // Correct ! f() est appel� une seule fois 
}

Quand vous d�clarez une fonction inline, elle a exactement l'aspect d'une fonction normale :

void f(int i, char c);

1
2
3
4
inline void f(int i, char c) 
{ 
    // ... 
}

Quand vous d�clarez inline une fonction membre, elle a exactement l'aspect d'une fonction membre normale :

1
2
3
4
class Fred { 
    public: 
        void f(int i, char c); 
};

1
2
3
4
inline void Fred::f(int i, char c) 
{ 
    // ... 
}

Oui : d�finissez la fonction de membre dans le corps de classe elle-m�me :

1
2
3
4
5
6
7
8
class Fred 
{ 
public: 
    void f(int i, char c) 
    { 
        // ... 
    } 
};