Intérêt de inline

**Maria1505** · 02/01/2007, 22h42

bonjour, quelle est l'utilité de la fonction inline !

**elraton** · 02/01/2007, 22h46

Hum hum hum,

les faq sont aussi la pour etre lu

http://c.developpez.com/faq/cpp/?page=inline

Et si jamais tu trouve pas dans la FAQ, utilise le moteur de recherche
http://c.developpez.com/faq/cpp/?rechercher=inline

**super_dek** · 02/01/2007, 23h08

l'interet c'est de gagner du temps...

En C++, on gagne beaucoup à écrire une fonction « en ligne » (inline).Par exemple Il suffit d’écrire :

inline int max(int a, int b)
{
if (a < b) return b; else return a;
}
Dans ce cas, le compilateur sait que chaque occurrence de l’appel de max devra être remplacée par le code de celle-ci.

mais une simple recherche t'aurais permis de le trouver rapidement.

**koala01** · 03/01/2007, 12h56

Salut,

La réponse courte tiens en deux mot: tres limité...

Pour la réponse longue, il faut commencer par une petite explication:

Tout part du constat que l'appel d'un fonction, au niveau du processeur, ca prend un temps bête(comprenons-nous... En temps processeur, 7 ou 8 fréquence d'horloge, c'est long, meme si ca ne fait que quelques nano secondes

)

Quand on crée une très petite fonction (je penses, entre autres, aux méthodes Get des classes) ou que l'on appelle très souvent une fonction, l'adage qui dit que ce sont les petits ruisseaux qui font les grand fleuve reste tout à fait vrai

...

L'idée du mot clé inline est donc de demander au compilateur, quand il rencontre la fonction, de remplacer l'appel de la fonction par le code qu'elle contient...

L'avantage, c'est que cela créera un exécutable plus rapide (du fait des sauts évités), mais aussi... plus lourd (vu que l'on trouvera peut etre 500 fois exactement les memes instructions... alors qu'on ne les aurait trouvées qu'une seule fois sans "l'inlining")

Du moins, si tout se passait comme la théorie le voudrait:

En effet, il y a des fonctions que le compilateur ne saura jamais "inliner" (je pense tout particulièrement aux fonctions récursives), et, pire encore, ce n'est pas parce que tu demandes au compilateur de créer une fonction inline qu'il le fera d'office, car il reste "seul juge" de la décision finale

A tel point qu'il est meme possible que le compilateur décide d'inliner certains appel à une fonction donnée, mais d'en gérer d'autres de manière tout à fait classique, et qu'il est possible que cette décision puisse engendrer certains problème au sein de l'exécutable (meme si j'ignore tout à fait les problèmes que ca peut engendrer

)

Bref, tout cela pour dire que, effectivement, l'intérêt du mot clé inline est très limité, et qu'il ne faut pas *forcément* compter dessus pour fournir un code *réellement* beaucoup plus rapide...

**bolhrak** · 03/01/2007, 13h38

Envoyé par koala01

L'avantage, c'est que cela créera un exécutable plus rapide (du fait des sauts évités), mais aussi... plus lourd (vu que l'on trouvera peut etre 500 fois exactement les memes instructions... alors qu'on ne les aurait trouvées qu'une seule fois sans "l'inlining")

Sauf si la traduction assembleur de ta fonction prend autant d'instructions ou moins qu'un appel de fonctions.

**koala01** · 03/01/2007, 14h07

Envoyé par bolhrak

Sauf si la traduction assembleur de ta fonction prend autant d'instructions ou moins qu'un appel de fonctions.

Ca, c'est vraiment l'exception qui confirme la regle et qui arrive, finalement très rarement...

Parce que, en y réfléchissant, une fonction, au niveau du processeur c'est

L'appel de la fonction (CALL <adresse> en assembleur si mes souvenirs sont bons)
les instructions de la fonction (immuable)
la reprise de l'exécution normale (dans la fonction, l'équivalent au return, dont j'ai oublié le terme en assembleur)

Il n'y ara donc que dans le cas ou la fonction peut etre traduite par une ou deux instructions processeur unique (charger un accu, ou similaire) que tu te retrouveras effectivement avec un code plus léger...

Au dela de deux instructions, l'exécutable sera, au mieux d'un poids égal, et, vraissemblablement plus lourd

(le gain de quelques fréquences d'horloge se traduit, de manière quasi systématique, et pour autant que l'algorithme de base soit efficace, par une augmentation du nombre d'instructions à effectuer

)

**bolhrak** · 03/01/2007, 14h30

4 instructions assembleur (de mémoire) pour les appels de fonctions ou fonctions membres non virtuelles; du coup ce n'est plus si anodin que ça, notamment pour les getters/setters, ou les appels chainés de fonction, genre une fonction A qui se contente d'appeler une fonction B.

Mais bon c'est clair que ce n'est pas non plus la majorité des cas, c'était plus par amour de la discussion

**loufoque** · 03/01/2007, 14h41

Ça dépend des machines...

**Médinoc** · 03/01/2007, 15h12

Vous oubliez l'empilement des paramètres, l'allocation sur la pile des variables locales à la fonction (frame pointer)...

À moins d'avoir une fonction "nue", l'appel peut être plus lourd qu'on le pense...

**koala01** · 03/01/2007, 22h43

Envoyé par Médinoc

Vous oubliez l'empilement des paramètres, l'allocation sur la pile des variables locales à la fonction (frame pointer)...

À moins d'avoir une fonction "nue", l'appel peut être plus lourd qu'on le pense...

De fait...

Mais, à moins de "s'amuser" à passer des parametres inutiles, il est fort probables que la multiplication des parametres aille de pair avec celle de ce que doit faire la fonction pour fournir son résultat...

Si l'on peut ergoter sur la limite d'instructions processeur en-dessous de laquelle une fonction inline fournira un exécutable plus léger que la meme fonction appelée de manière "traditionnelle" et au dela de laquelle la fonction inline fournira un exécutable plus lourd, et donc, par conséquent, sur la différence de poids de l'exécutable final, il n'en reste que la différence de poids tendra le plus souvent à allourdir la version inlinee...

Nous sommes confrontés au meme phénomene que celui qui apparait lorsqu'on "déroule" l'exécution d'une boucle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
for(i=0;i<x;i++)
   cout<<i;

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
cout<<0;
cout<<1;
cout<<2;
...
cout<<x-1;

fourniront le meme résultat...

la différence viendra de ce que la première version sera un peu plus lente -quelques nano secondes au pire, vu les processeurs actuels(du fait de la présence de saut pour la boucle) à moins d'avoir un x particulièrement élevé- et que, si, dans la première version, on se retrouve avec un nombre équivalent à T1=I+J d'instructions processeur (où T est le total, I, le nombre d'instructions nécessaire à l'initialisation de la boucle et J le nombre d'instructions pour provoquer l'affichage), nous nous retrouverons dans la seconde version avec un nombre total équivalant à T2=J*x...

De fait, la premiere version pourra etre plus lourde que la seconde, mais si et seulement si T2 est plus petit que T1 pour un résultat équivalent, ce qui ne pourra arriver que pour un x d'autant plus bas que I est peu élevé... autrement dit de manière plutot anecdotique