Discussion :

[Aurelien.Regat-Barrel]

Bonjour,

En ce moment je passe des entretiens et donc des tests techniques C++, et j'ai eu droit à une question sur "virtual inline". J'en ai profité pour glisser mon avis personnel au sujet de inline qui est en gros : ce n'est plus utile de nos jours. Maintenant, je me demande dans quelle mesure mon affirmation est valide.

Je n'ai jamais été un grand fan de inline (explicite ou implicite), parce que de mon point de vue c'est une entorse aux bonnes pratiques (pas d'implémentation dans un header) du fait que, ben, on en avait besoin. Mais aujourd'hui - sans m'être sérieusement penché sur la question je l'avoue - j'estime que les compilateurs sont suffisamment évolués pour se débrouiller tout seuls, surtout avec l'apparition de l'optimisation guidée par profil (encore que j'ai eu des déceptions à ce sujet). Bref, je considère qu'inline relève de l'optimisation prématurée, pour ne pas dire de la pollution de code, et que c'est à oublier au même titre que register.

Vos avis / retours d'expérience ?

[Matthieu Brucher]

Idem, le compilateur fait très bien son boulot, s'il voit que la fonction a un intérêt en terme de quantité d'instructions à être inlinée, elle le sera, même si elle est en double.
Ce qui est certain, c'est que quand mon code est inliné par le compilateur, je gagne un facteur 10 car tous les appels "simples" sont regroupés (c'était l'objectif au départ du programme).

[Alp]

Bref, je considère qu'inline relève de l'optimisation prématurée, pour ne pas dire de la pollution de code, et que c'est à oublier au même titre que register.

Ca résume très bien mon avis.

Les compilos que j'utilise (celui de VC et gcc), en particulier VC au boulot, gèrent très bien ça. Je ne m'en soucie pas et considère ne pas avoir à m'en soucier. Cela fait partie de ce que l'on est en droit d'exiger d'un compilateur de nos jours.

PS : ils comptaient vraiment t'avoir avec le coup du "virtual inline" ?

[JolyLoic]

J'aurais bien aimé une troisième réponse au sondage : C'est inutile en général, mais on ne sait jamais.

Tout ce que je sais, c'est que ça fait un bout de temps que je n'ai pas fait de micro-optimisations de code en général, car je n'en n'avait pas vraiment besoin. Inline rentre dans la catégorie micro-optimisation. Le jour où j'aurais à micro-optimiser, j'essayerai inline comme d'autre techniques, en mesurant le résultat. Je n'ai pas envie de le rejeter a priori, on ne sait jamais, mais il est clair que je ne l'utiliserais que de façon hyper ponctuelle...

[koala01]

Salut,

à défaut d'une possibilité plus nuancée, j'ai voté que c'est obsolète et à oublier...

Surtout si l'idée est de créer... une fonction virtuelle

Mais même en dehors de ce cas "peau de banane", je trouve que cela fait vraiment partie des optimisations prématurées tant il y a de restrictions au niveau du compilateur qui nous empêchent d'avoir la certitude que tous les appels à une fonction seront bel et bien inlinés

[metagoto]

inline peut servir à ne pas avoir de multiples définitions de templates.

Ca peut être utile aussi pour remplacer ce que l'on pourrait faire avec des macros. MACHIN(++x) --> machin(++x)

OK pour laisser le compilo décider d'inliner ou non, mais OK aussi pour laisser le développeur placer des keywords inline qui vont bien dans certains cas.

[Matthieu Brucher]

Ca peut être utile aussi pour remplacer ce que l'on pourrait faire avec des macros. MACHIN(++x) --> machin(++x)

Le compilateur fait ça bien mieux que toi, je ne vois l'intérêt de lui forcer ça !
Pour les templates, c'est idem, il inline automatiquement quand c'est possible/intéressant pour ton processeur.