Discussion :

[Kaluza]

Bonjour.

J'avais 2 questions à propos des fonctions inline :
1) Dans quels fichiers déclarer les fonctions inline ? Dans les .h ou dans les .cpp ?
2) A quoi se limiter au niveau des fonctions inline ?
Juste à 2/3 if et à des return ou cela peut être plus complexe ?
De plus peut-on déclarer des variables (variables temporaire pour des calculs par exemple) dans une fonction inline ou cela n'a aucun sens et la fonction ne sera pas inlinée par le compilateur ?

Merci

[LittleWhite]

Bonjour,

1) Le corps de la fonction dans être le .h
2) Pour les limites ... hum ... la dernière fois que nous avons parler des inline ici, ce fut un débat pour savoir si le mot clé était encore d'actualité. Personnellement, je ne sais toujours pas quand mettre inline ou pas, et je fais confiance à mon compilateur.

Sinon, dans le principe, le inline équivaut à une copie de la fonction là où son appel est fait. Donc dans une fonction inline, on peut bien déclaré une variable.

[koala01]

Salut,

Pour être précis sur la réponse à la première question, il faudrait dire: "dans un fichier qui sera inclus (de manière directe ou indirecte) dans le fichier dans lequel l'appel de la fonction sera effectué".

La différence avec la réponse de LittleWhite est subtile, mais elle peut prendre toute son importance dans le cadre de fonctions (membres de classes) template, qui, elles, devront d'office être déclarée inline, que ce soit de manière implicite (parce que définies dans le corps de la classe template dont elles sont membres) ou explicite.

Pour la deuxième réponse, on va faire simple: pour les fonctions particulièrement courtes (typiquement: mutateurs et accesseurs) et pour les fonctions (membres de classes) template.

Pour les fonctions courtes, qui correspondent quasiment, comme LittleWhite l'a fait remarquer, à la déclaration d'une variable, il est plus que possible que la fonction sera effectivement inlinée.

Pour les fonctions (membres de classes) template, c'est nécessaire pour:

1. permettre au compilateur de produire le code binaire exécutable correspondant au type avec lequel la fonction est utilisée
2. éviter à l'éditeur de liens de se plaindre du fait qu'il retrouve potentiellement plusieurs implémentation d'une même fonction (utilisant le même type) dans différents fichiers objets

Pour les autres fonction, il faut savoir que la déclaration (implicite ou explicite) d'une fonction inline se "contente" d'indiquer au compilateur que tu souhaite que l'appel à la fonction soit remplacé par le corps de la fonction directement dans le code objet, mais qu'il n'a aucune obligation de s'y tenir.

Il ne décidera d'inliner effectivement une fonction que si (et seulement si) le code binaire qu'elle représente demande moins d'un certains nombre (que l'on peut le cas échéans redéfinir avec l'option ad-hoc) d'instructions processeur .

[3DArchi]

Un dernier point : une fonction inline présentant sa définition peut amener à rajouter des dépendances entre des fichiers, dépendances qui relèvent du détail d'implémentation. Ce qui peut être assez embêtant en maintenance ou tout simplement en compilation.

[David Fleury]

Ne pas les utiliser ?

[oxyde356]

Ne pas les utiliser ?

Là il faut que tu argumente parce que c'est vraiment pas commun comme proposition

On peut rajouter qu'il est bon d'inliner des petites fonctions appelées très souvent mais à peu d'endroits différents.

Personnellement je ne les met pas directement dans le .h, j'ajoute un fichier .inl (que le .h inclus tout à la fin) qui définit les fonctions inline. Je trouve ça plus clair, ça sépare la déclaration de la définition.

[David Fleury]

Il le fera mieux que moi.

http://www.gotw.ca/gotw/033.htm

[oxyde356]

Pas vraiment convaincant

[Flob90]

Pas vraiment convaincant

Sutter argumente quand même, j'en vois 2 :

- Ne jamais faire d'optimisation (ici inilner) sans savoir où le besoin d'optimisation est localisé, c'est à dire après être passé par un profiler. Et toujours vérifier ses algos avant de s'attaquer à des micro-optimisation (comme passer une fonction inline). C'est un argument classique contre les micro-optimisation prématuré il me semble.

Cette argument se base sur le fait qu'indiquer inline c'est dire au compilo : "tu peux inliner" et pas "tu dois inliner", et que donc on ne peut pas (ou plus exactement que ca serait une perte de temps) faire le raissonement inverse (tout inliner et désinliner au besoin).

Il se base aussi sur le fonctionnement de l'inline pour montrer qu'il peut augmenter ou diminuer les perfs de ton programme (que ce soit taille ou vitesse).

- Inliner induit un couplage fort, c'est un argument de conception assez fort : couplage fort = à éviter. (Il détaille plus cette idée dans un article sur l'héritage, et de manière général tout les concept OO tentent à réduire les couplage fort, ils induisent une rigidité du code impropre à l'évolution du programme).

Finalement je trouve au contraire qu'il est plutôt convaincant, et la conclusion n'est pas "jamais inliné" mais éviter d'inliner (*) avant d'être certain que les perfs en profitent et que le design n'en patisse pas trop.

(*) Sauf quand c'est obligatoire comme pour les fonction membre template.