Centre Informatique pour les Lettres

et les Sciences Humaines

Apprendre C++ avec Qt : Annexe 6
Fonction i nl i ne


Lorsqu'une fonction dpourvue d'argument est appele, la squence de code excute
ressemble beaucoup celle qui aurait t obtenue en insrant le code dfinissant cette fonction
la place de l'instruction qui l'a appele. Imaginons par exemple que deux fonctions soient
dfinies de la faon suivante :

voi d f onct i onAppel ee( ) 1
{ 2
cout << " J e sui s l ! " ; 3
} 4

voi d f onct i onAppel ant e( ) 1
{ 2
cout << " Dbut de l ' excut i on " << endl ; 3
f onct i onAppel ee( ) ; 4
cout << " Fi n de l ' excut i on " << endl ; 5
} 6

Le rsultat obtenu lors de l'excution ressemble fort celui qu'aurait produit l'excution de

voi d f onct i onUni que( ) 1
{ 2
cout << " Dbut de l ' excut i on " << endl ; 3
cout << " J e sui s l ! " ; 4
cout << " Fi n de l ' excut i on " << endl ; 5
} 6

Du point de vue de l'criture du programme, les deux situations sont trs diffrentes, surtout
si la f onct i onAppel ee( ) est un peu complexe et est appele plusieurs fois. Par ailleurs, si la
f onct i onAppel ee( ) possde des paramtres, le code qui pourrait remplacer son appel dpend
des valeurs transmises.

Du point de vue de l'excution, en revanche, la diffrence essentielle est que la premire
approche impose une sauvegarde de l'tat d'avancement de l'excution de la
f onct i onAppel ant e( ) , l'initialisation des ventuels paramtres de la f onct i onAppel ee( )
avec les valeurs transmises, puis une restauration de l'tat d'avancement de la
f onct i onAppel ant e( ) une fois l'excution de la f onct i onAppel ee( ) termine.

Lorsque la fonction est trs brve, ces oprations "administratives" ont un cot qui cesse d'tre
ngligeable par rapport la dure d'excution de la fonction. Pour viter aux programmeurs la
tentation d'essayer d'obtenir une excution plus rapide en s'abstenant de crer ce genre de
fonctions, le langage C++ permet de demander que certaines fonctions ne soient pas rellement
appeles, mais que le compilateur remplace effectivement leur appel par le code quivalent. Il
suffit pour cela que, lors de sa dfinition, le nom de la fonction soit prcd du mot inline :

i nl i ne voi d f onct i onAppel ee( ) 1
{ 2
cout << " J e sui s l ! " ; 3
} 4

Il faut toutefois souligner qu'il ne s'agit l que d'un souhait exprim par le programmeur. Le
compilateur reste, en tout tat de cause, l'arbitre de ce qui peut ou non tre ralis "i nl i ne".

La notion de fonction i nl i ne appelle en outre un dernier commentaire : les fragments de code
ainsi dfinis n'ont plus de fonction que le nom, puisque le mcanisme que leur invocation
dclenche n'est prcisment pas celui d'un appel de fonction. Cette diffrence a une
consquence pratique importante : le compilateur doit disposer du code correspondant la
Document du 23/08/05 - Retrouvez la version la plus rcente sur http://www.up.univ-mrs.fr/wcpp
C++ - Annexe 6 Fonction i nl i ne 2/2

"fonction" au moment o il traite un "appel" celle-ci, puisque cet appel doit justement tre
remplac par le code en question. Le principe d'autonomie de compilation des .cpp interdit
donc que les fonctions i nl i ne soient dfinies dans des fichiers .cpp. Par consquent,

Lorsqu'une fonction est i nl i ne, sa dfinition doit figurer dans un .h et non dans un .cpp

Bien entendu, ce fichier .h devra tre inclus dans tout .cpp o figure un appel la fonction
i nl i ne concerne. Comme une fonction i nl i ne n'est pas vritablement une fonction, la
prsence de sa dfinition dans un .h ne pose pas de problme de redfinition en cas
d'inclusions multiples de ce .h dans un projet. C'est d'ailleurs cette tolrance la redfinition
prsente par les fonctions i nl i ne qui explique qu'on puisse dfinir une fonction membre au
cours de la dfinition d'une classe (c'est dire dans un .h, qui a vocation tre inclus
plusieurs fois dans le mme projet). En effet,

Lorsqu'une fonction membre est dfinie l'intrieur la dfinition de la classe laquelle elle
appartient, sa dfinition est automatiquement considre comme tant i nl i ne.
J-L Pris - 23/08/05