bonjour, quelle est l'utilité de la fonction inline !
Version imprimable
bonjour, quelle est l'utilité de la fonction inline !
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
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.
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 8O ...
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"):P
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 :P
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 :P)
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...
Sauf si la traduction assembleur de ta fonction prend autant d'instructions ou moins qu'un appel de fonctions.Citation:
Envoyé par koala01
Ca, c'est vraiment l'exception qui confirme la regle et qui arrive, finalement très rarement...Citation:
Envoyé par bolhrak
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 ;) )
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 :lol:
Ça dépend des machines...
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...Citation:
Envoyé par Médinoc
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:
etCode:
2
3
fourniront le meme résultat...Code:
2
3
4
5
6
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 :P
Il y a un autre cas d'exception, c'est si la fonction n'est appelée que depuis un seul point dans le programme.Citation:
Envoyé par koala01