Intérêt de "inline" de nos jours : pour ou contre ?

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 ?

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).

Citation:

---

Envoyé par Aurelien.Regat-Barrel

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" ? :mrgreen:

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...

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 :P

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

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.

Citation:

---

Envoyé par metagoto

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.

Citation:

---

Envoyé par Matthieu Brucher

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.

---

On est parfois obligé d'inliner des définitions de templates si on les places dans des fichiers headers.

Et pour le "remplacement de macro", même si le compilo fait ce qu'il veut, je trouve personnellement que de mettre inline exprime mieux l'intention du développeur

Citation:

---

Envoyé par Matthieu Brucher

Citation:

---

Envoyé par 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.

---

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.

---

D'autant plus que la seule restriction à l'utilisation des template est... que le compilateur dispose de l'implémentation des fonctions afin de pouvoir créer le code binaire correspondant une fois qu'il a déterminé le type de donnée manipulée...

Il est ainsi tout à fait possible d'envisager la création de fonctions virtuelles au sein de classes template alors que les fonctions virtuelles ne sont, par définition, jamais inlinées ;)

Citation:

---

On est parfois obligé d'inliner des définitions de templates si on les places dans des fichiers headers.

Et pour le "remplacement de macro", même si le compilo fait ce qu'il veut, je trouve personnellement que de mettre inline exprime mieux l'intention du développeur

---

C'est exactement le problème que j'avais eu dans ce post: http://www.developpez.net/forums/d58...tion-template/
Donc pour moi le mot clef inline est encore totalement d'actualité!

Je viens de répondre sur l'autre thread, inline ne fait que corriger des définitions multiples.

Ce qui pour moi, est suffisant pour continuer à l'utiliser.

Je n'ai pas voté, il manque l'option "il est important de savoir ce que c'est mais de ne l'utiliser qu'à bon escient".

L'inlining n'est jamais garanti, même avec le "inline" explicite. Par conséquent, côté optimisations au quart de poil, il vaut souvent mieux une bonne vieille macro qu'un mot-clé "inline".
Côté performances globales, il vaut souvent mieux laisser le compilateur inliner à sa guise : toutefois, déclarer les fonctions "inline" peut l'aider à faire des choix peut-être plus judicieux.

Je pense donc que c'est intéressant d'ajouter un "inline" sur les fonctions qui en profiteraient le plus (accesseurs par exemple), afin d'aiguiller les choix du compilateur et/ou d'être à peu près certain que les fonctions en question seront en tête de liste d'inlining.
Par contre, il est stupide de ne se fier qu'à un mot-clé "inline" pour optimiser une boucle critique.

Ça me fait plaisir d'entendre que le compilateur sait très bien inliner pour moi :p

Je n'ai pas du tout votre niveau, je connais ce que fais inline, mais je serai incapable de dire où il est judicieux d'en placer un.
La règle que j'utiliserai si je voulais en placer un, serait, j'en place un, car ma fonction est petite ( 5 lignes ... une sorte de raccourci )( ? ) ...
Tout ça, à cause d'un prof, qui avait dit d'inliner une fonction qui génère des nombres aléatoires entre un min et un max en float ( avec la fonction rand ).
La fonction est petite, prend deux valeurs, ne fait que trois 4 calcul + l'appel à rand.
Retourne le résultat.

Qu'en pensez vous ?

J'en pense que le mieux s'il y a vraiment des problèmes de perfs dans ce programme est de tenter les deux version et de voir (=mesurer) s'il y a un écart notable. S'il n'y en a pas (et il y a des chances qu'il n'y en ait pas), garder la version non inline.

Citation:

---

Envoyé par Mac LAK

Je n'ai pas voté, il manque l'option "il est important de savoir ce que c'est mais de ne l'utiliser qu'à bon escient".

---

Yes, mais je n'arrive pas à éditer mon sondage :oops:


Bon, aujourd'hui j'ai passé un autre entretien où j'ai mis le nez dans le code de leur logiciel etc... et en voyant un header de classe chargée d'effectuer des operations mathématiques (du type vecteurs etc...), y'avait du inline partout, et quelque part, j'ai trouvé ça... rassurant. En fait, je pense qu'au niveau technique l'utilité de ce mot-clé est réellement contestable (je suis d'accord avec Matthieu au sujet du problème de template, pour moi cette utilisation de inline est une pirouette qui sert à masquer un autre problème en fait).

Mais c'est vrai qu'on est habitué à ce mot-clé, qu'on est conditionné quelque part à l'utiliser sur des classes un peu sensibles (au même titre qu'on est conditionné à ne pas utiliser goto), et alors, ne pas lire "inline" peut faire germer le petit doute "et si le compilo n'optimisait pas ma petite classe sensible ?

Je reste convaincu que d'un point de vue purement technique, c'est du bidon et que les vrais problèmes d'optimisation sont ailleurs que dans l'inlining de quelques getters, mais je reconnais maintenant que ça permet de se donner une bonne conscience (ça va un peu dans le sens de la remarque de metagoto sur l'intention du programmeur), de se rassurer en n'ayant pas à profiler le code en question pour être sûr que le compilo fait bien son boulot. A moins que, au contraire, ce soit l'occasion de tester et vérifier par soi même que le compilo sait très bien gérer ça et que inline est véritablement devenu inutile... je testerai si je suis embauché !

Ce qui me gêne toujours avec ce mot-clé, c'est que selon moi il procure une fausse bonne conscience et détourne des véritables sujets d'optimisation en encourageant le développeur à se focaliser sur des setter / getter au lieu de se pencher sur sa gestion mémoire par exemple. Car concrètement, au même titre que l'on ne prend pas le temps d'évaluer l'auto-inlining du compilateur, on ne le prend pas de mesurer le véritable gain de tous ces inline que l'on met partout. Peut-être que ça ne produit aucun résultat visible alors que ça alourdit le code source. C'est grosso-modo ce que j'ai voulu exprimer dans mon premier message.

En fait, le compilateur va principalement regarder le nombre de pseudo instructions lorsqu'il doit décider s'il inline une fonction ou non...

Tu ne peux donc pas réellement te baser sur le fait qu'une fonction n'utilise que deux valeurs et trois calcul pour voir s'il est oui ou non intéressant de le faire, à moins de savoir pertinemment la manière dont le calcul sera transformer en instruction assembleur :D

Mais, ceci dit, il faut savoir que de nombreux outils de profiling éprouvent des problèmes avec les fonctions inline et que, de toutes manières, la perte de temps due à l'empilement des appels tient en définitive à quelques cycles d'horloges...

Et comme il y a malgré tout certaines restrictions à l'inlining comme les fonctions membres virtuelles ou certaines fonctions récursives et que même un simpel accesseur peut en faire plus que ce que l'on pourrait croire (parfois par simple distraction du programmeur), je pense sincèrement qu'il est préférable d'attendre d'être en mesure de constater "sur pièce" qu'une fonction présente un réel goulot d'étranglement et de commencer par retravailler l'algorithme (qui peut remonter bien haut :D) avant de décider d'inliner une fonction ;)

En effet, si tu te trouve dans une situation proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

void fonctionA() { /* très petite fonction qui pourrait être inlinée */ } void fonctionB() { for(int i=0;i<1000;++i) fonctionA(); } void fonctionC() { for(int i=0;i<1000;++i) fonctionB(); } /* on pourrait continuer ainsi longtemps :D */

---

Le gain occasionné par le fait de simplement pouvoir éviter 100 fois d'appeler fonctionB dans la boucle de fonctionC sera autrement plus important que celui occasionné par l'inlining de fonctionA() et le fera passer pour superflu, ou peu s'en faut :D

car, si l'inlining de fonctionA te permet effectivement de gagner un million de fois quelques cycles d'horloges, le seul fait de n'invoquer que 900 fois fonctionB (et donc 900 000 fois fonctionA) t'en fera gagner bien plus... surtout si la boucle n'est qu'une partie de la logique :D
Pour la petite histoire,gcc par exemple permet de définir le nombre de pseudo instructions en dessous duquel il doit garder une fonction inline :D

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Mais c'est vrai qu'on est habitué à ce mot-clé, qu'on est conditionné quelque part à l'utiliser sur des classes un peu sensibles (au même titre qu'on est conditionné à ne pas utiliser goto), et alors, ne pas lire "inline" peut faire germer le petit doute "et si le compilo n'optimisait pas ma petite classe sensible ?

Je reste convaincu que d'un point de vue purement technique, c'est du bidon et que les vrais problèmes d'optimisation sont ailleurs que dans l'inlining de quelques getters,

---

Moi aussi :D

Citation:

---

mais je reconnais maintenant que ça permet de se donner une bonne conscience (ça va un peu dans le sens de la remarque de metagoto sur l'intention du programmeur),

---

J'aurais presqu'envie de dire "pourquoi devoir se donner bonne conscience", mais je dirai plutôt:

Ca permet d'indiquer l'intention du programmeur... Mais est-ce suffisant pour rassurer sur ce que le compilateur fait effectivement :question:

Après tout, c'est quand même lui qui a le dernier mot :aie:

Citation:

---

de se rassurer en n'ayant pas à profiler le code en question pour être sûr que le compilo fait bien son boulot.

---

Je dirais plutôt que cela devrait nous obliger à vérifier que le compilo fait bien son boulot...

Une fonction sensée être inlinée et qui ne l'est en réalité pas posera sans doute beaucoup plus de problèmes de performances que l'inverse (à moins que la taille de l'exécutable ne soit le problème principal du projet ;))

Citation:

---

A moins que, au contraire, ce soit l'occasion de tester et vérifier par soi même que le compilo sait très bien gérer ça et que inline est véritablement devenu inutile... je testerai si je suis embauché !

---

Tiens nous au courent:D

Citation:

---

Ce qui me gêne toujours avec ce mot-clé, c'est que selon moi il procure une fausse bonne conscience et détourne des véritables sujets d'optimisation en encourageant le développeur à se focaliser sur des setter / getter au lieu de se pencher sur sa gestion mémoire par exemple. Car concrètement, au même titre que l'on ne prend pas le temps d'évaluer l'auto-inlining du compilateur, on ne le prend pas de mesurer le véritable gain de tous ces inline que l'on met partout. Peut-être que ça ne produit aucun résultat visible alors que ça alourdit le code source. C'est grosso-modo ce que j'ai voulu exprimer dans mon premier message.

---

+1...

Le mot clé inline ne fait que demander au compilateur de remplacer l'appel de la fonction par son implémentation, alors qu'il reste (à peu près) libre de décider de le faire ou non.

Je ne nie absolument pas qu'il ait pu être intéressant aux temps des pionniers ou le moindre cylce comptait, mais j'ai la conviction qu'il est largement préférable de pouvoir mesurer l'impact réel de l'inlining d'une fonction plutôt que d'en mettre partout.

Dans quelques cas particuliers, ce sera effectivement la "seule" chose à faire, dans tous les autres, cela généralement à vouloir faire ce qui se trouve au numéro 97 d'une liste de priorités alors que l'on en est qu'au numéro 5 :P

C'est toujours d'actualité, si la fonction n'est pas inline et se situe dans un fichier d'entête, on aura des problèmes à l'édition de liens.

Citation:

---

Envoyé par loufoque

C'est toujours d'actualité, si la fonction n'est pas inline et se situe dans un fichier d'entête, on aura des problèmes à l'édition de liens.

---

+1

Code:

---

grep -r ^inline boost_1_39_0/boost | wc -l

---

+6187

Ca a son utilité, surtout pour les librairies headers-only. Et oui, je suis globalement d'accord avec ceux qui pensent que le compilo sait et fait mieux son job que le programmeur. Mais ça n'est qu'une facette de l'utilité du mot-clé inline. Matthieu Brucher a fait cependant une judicieuse remarque, le fait qu'une spécialisation complète (de function template) puisse être définie dans sa propre translation unit avec un linkage externe. Mais pour du header-only, ou du partial specialization, on n'a guère le choix.

En résumé (selon moi):
+1 pour controller le linker
+0 pour controller le compiler
---
+1

Citation:

---

Envoyé par koala01

Mais, ceci dit, il faut savoir que de nombreux outils de profiling éprouvent des problèmes avec les fonctions inline et que, de toutes manières, la perte de temps due à l'empilement des appels tient en définitive à quelques cycles d'horloges...

---

Pour moi, le gros avantage de l'iniling (manuel ou décidé par l'ordinateur) tient au moins autant à la possibilité d'optimiser le code au delà de la frontière de l'appel de fonction qu'à la suppression de cet appel.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Ce qui me gêne toujours avec ce mot-clé, c'est que selon moi il procure une fausse bonne conscience et détourne des véritables sujets d'optimisation en encourageant le développeur à se focaliser sur des setter / getter au lieu de se pencher sur sa gestion mémoire par exemple.

---

Si l'inlining a pour effet que l'on ajoute des getters/setters à ses classes malgré le fait que ça en diminue l'encapsulation, je considère ça comme un effet négatif :)

Citation:

---

Envoyé par koala01

Mais, ceci dit, il faut savoir que de nombreux outils de profiling éprouvent des problèmes avec les fonctions inline et que, de toutes manières, la perte de temps due à l'empilement des appels tient en définitive à quelques cycles d'horloges...

---

C'est plus que le compilateur ne laisse pas forcément ces informations ! GCC est bien connu pour ça, même le débuggage de programmes en O3 peut être pénible. En revanche, les infos de Visual Studio sont toujours complètes (au moins de ce que j'ai pu voir).
Enfin, quand tu codes proprement et que tu as des boucles sur des millions d'éléments, tu es bien content de la suppression des appels, car un appel signifie sauvegarde des registres, passage des arguments sur la pile, et idem à la sortie. Quand ta fonction interne est courte, tu peux avoir des facteurs d'accélération impressionnants.

Au fait, question bête, tu as répondu quoi à "virtual inline" ?

Citation:

---

Envoyé par JolyLoic

Pour moi, le gros avantage de l'iniling (manuel ou décidé par l'ordinateur) tient au moins autant à la possibilité d'optimiser le code au delà de la frontière de l'appel de fonction qu'à la suppression de cet appel.

---

Sauf que tu ne peux jamais être certain de l'inlining, la directive pouvant être ignorée par le compilateur. La seule chose sûre avec l'inlining, c'est que tu peux garantir (par l'absence de directive et les options de compilation adéquates) qu'une fonction que tu ne veux pas inliner ne le sera effectivement pas... Ceci n'a toutefois guère d'intérêt de façon générale, sauf si l'on doit compiler en faveur de la taille du code binaire bien sûr (ce qui est un cas relativement rare, tout de même).

Du coup, si tu as un code réellement critique à optimiser, où l'inlining offre réellement des gains mesurables, il vaut souvent mieux transformer ta fonction inline en bonne vieille macro... C'est la seule manière d'assurer à 100% une traduction en inline quel que soit le compilateur et/ou les flags de compilation.

Citation:

---

Envoyé par Mac LAK

Du coup, si tu as un code réellement critique à optimiser, où l'inlining offre réellement des gains mesurables, il vaut souvent mieux transformer ta fonction inline en bonne vieille macro... C'est la seule manière d'assurer à 100% une traduction en inline quel que soit le compilateur et/ou les flags de compilation.

---

Franchement, le compilateur sait très bien faire tout seul cela (comme je l'ai déjà dit, sur un code critique, l'inlining automatique m'a fait gagné un facteur 10), je ne vois pas l'intérêt de perdre le typage pour introduire des erreurs (surtout que si c'est une macro, soit c'est suffisamment court pour que le compilo inline à coup sûr, soit c'est trop gros pour que ça ne soit pas dangereux d'être une macro).

Citation:

---

Envoyé par Mac LAK

Du coup, si tu as un code réellement critique à optimiser, où l'inlining offre réellement des gains mesurables, il vaut souvent mieux transformer ta fonction inline en bonne vieille macro... C'est la seule manière d'assurer à 100% une traduction en inline quel que soit le compilateur et/ou les flags de compilation.

---

Si je suis un jour dans cette situation (et je ne m'y suis encore jamais trouvé), je préfèrerai à coup sur utiliser des mots clefs spécifiques à un compilateur (__forceinline par exemple avec VC++) qu'une macro...

Je me pose une question à propos de ces inline.
Etant donné que :
préciser qu'une fonction est inline n'est qu'une suggestion au compilateur, qui n'est pas obligé de la suivre
quand on ne précise pas inline, le compilateur peut tout de même rendre la fonction inline si il trouve cela judicieux

Du coup, quel est l'intérêt de préciser inline puisque le compilateur n'en fait de toute façon "qu'à sa tête" ? (j'exagère un peu, je me doute que quand on lui suggère il y a plus de chances que la fonction devienne inline que quand on ne lui suggère pas, néanmoins inline reviendrait en fait à dire, "augmente de 15% la probabilité que cette fonction devienne inline" ?)

Corrigez moi si je me trompe.

Le seul intérêt est qu'il n'exporte pas le nom de la fonction en dehors de l'unité de compilation. Donc ça permet de pallier à des erreurs de conception.

Citation:

---

Envoyé par Matthieu Brucher

Le seul intérêt est qu'il n'exporte pas le nom de la fonction en dehors de l'unité de compilation. Donc ça permet de pallier à des erreurs de conception.

---

Il y a des choses qui m'échappent :
- si le compilateur ne suit pas le conseil qu'on lui donne de mettre une fonction inline, le nom de la fonction sera "exporté en dehors de l'unité de compilation" non ?
- pourquoi le fait de ne pas "exporter le nom de la fonction en dehors de l'unité de compilation" pallie les erreurs de conception ?

Edit: c'est la fin de la semaine, j'avais écrit volatile à la place de inline...

Citation:

---

Envoyé par Matthieu Brucher

Franchement, le compilateur sait très bien faire tout seul cela (comme je l'ai déjà dit, sur un code critique, l'inlining automatique m'a fait gagné un facteur 10), je ne vois pas l'intérêt de perdre le typage pour introduire des erreurs (surtout que si c'est une macro, soit c'est suffisamment court pour que le compilo inline à coup sûr, soit c'est trop gros pour que ça ne soit pas dangereux d'être une macro).

---

Je parle bien de code réellement critique, pas juste de l'inlining automatique "classique".
De façon générale, tu as raison, et/ou il peut être intéressant de voir les options spécifiques des compilateurs (à condition qu'ils en aient, cependant).

Passer en macro, c'est surtout pour passer outre tout flag de compilation et/ou spécificités du compilateur. Comme cela peut être difficile à maintenir, c'est bien entendu à réserver aux cas très pointus le demandant.

Citation:

---

Envoyé par thetux

Il y a des choses qui m'échappent :
- si le compilateur ne suit pas le conseil qu'on lui donne de mettre une fonction volatile, le nom de la fonction sera "exporté en dehors de l'unité de compilation" non ?

---

Non. Elle est inline, elle a pour vocation de ne pas être exportée.

Citation:

---

Envoyé par thetux

- pourquoi le fait de ne pas "exporter le nom de la fonction en dehors de l'unité de compilation" pallie les erreurs de conception ?

---

Dans le cas où cette fonction vit dans un en-tête, le inline est indispensable, mais c'est une erreur de débutant qu'on essaie de masquer.

Mais il y a des fonctions qui ont vocation à être dans un en-tête: Notamment, certaines fonctions utilisées en complément d'une macro (ben oui, on ne peut pas toujours se débarrasser complètement de ces dernières).

Et puis, ne pas oublier que tout le monde ne compile pas en LTCG, sans compter les cas où la LTCG ne sert à rien (distribution de bibliothèque). Dans ces cas, l'inlining automatique n'est pas possible, et seule reste l'option de définir la fonction en inline dans un header...

Citation:

---

Envoyé par thetux

Il y a des choses qui m'échappent :
- si le compilateur ne suit pas le conseil qu'on lui donne de mettre une fonction volatile, le nom de la fonction sera "exporté en dehors de l'unité de compilation" non ?
- pourquoi le fait de ne pas "exporter le nom de la fonction en dehors de l'unité de compilation" pallie les erreurs de conception ?

---

"Simplement" parce que l'on a trop souvent tendance à perdre demeter de vue...

Lorsque tu crées une classe ou une fonction template, nous sommes d'accord avec le fait que c'est pour te permettre de l'adapter en fonction du type de donnée réellement manipulée.

Mais les manipulations adaptées à une données particulière ne devrait se trouver que dans une unité de compilation donnée, les autres unités de compilation devraient se "contenter" de savoir que l'on peut effectivement utiliser la fonction.

Dans l'idéal, tu devrais donc avoir une séparation claire entre la déclaration des fonctions template et leur implémentation.

Pour la grosse majorité des unités de compilation, seule la connaissance de l'existence des classes et des fonctions est suffisante, l'implémentation ne les intéressant normalement pas.

Un fichier d'en-tête proche de
MyClass.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

/* ce fichier ne fait que déclarer les fonctions et définir la classe, et ce  * devrait être suffisant pour une grosse majorité des unités de compilation  */ template <class T> class MyClass { public: MyClass(); ~MyClass(); void foo(); static void bar(); private: T data; int truc; static Type machin; };

---

Tu aurais une implémentation séparée proche de
MyClass.tpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

//il faut bien que le compilateur connaisse la classe   #include <MyClass.h> template <class T> Type MyClass<T>::machin=Type(); template <class T> MyClass<T>::MyClass():data(),truc(0){} template <class T> MyClass<T>::~MyClass(){} template <class T> void MyClass<T>::foo() { /*...*/ } template <class T> void MyClass<T>::bar() { /*...*/ }

---

Et enfin, tu aurais une unité de compilation qui manipule explicitement MyClass en déterminant le type de T et étant seule responsable de la gestion de la spécialisation effective:
OtherClass.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

/* selon le cas, l'un ou l'autre sont envisageable */ template <class T> class MyClass; class OtherClass { public: /*...*/ private: MyClass<int> obj; }; /* OU - OU - OU */ #include <MyClass.h> class OtherClass : public MyClass<OtherClass> //par exemple { public: /*...*/ private: };

---

OtherClass.cpp

Code:

---

1 2 3 4 5 6

/* pour ne fournir l'implémentation de MyClass<int> qu'à cette unité de  * compilation  */ #include <MyClass.tpp> /* implémentation des fonctions et des membres statiques de OtherClass */

---

Au pire, la connaissance des possibilités offertes par MyClass pour un type particulier ne devrait passer que par la connaissance de l'unité de compilation qui manipule effectivement ce type d'objet ;)

Citation:

---

Envoyé par Médinoc

Mais il y a des fonctions qui ont vocation à être dans un en-tête: Notamment, certaines fonctions utilisées en complément d'une macro (ben oui, on ne peut pas toujours se débarrasser complètement de ces dernières).

Et puis, ne pas oublier que tout le monde ne compile pas en LTCG, sans compter les cas où la LTCG ne sert à rien (distribution de bibliothèque). Dans ces cas, l'inlining automatique n'est pas possible, et seule reste l'option de définir la fonction en inline dans un header...

---

Rien n'oblige cette fonction à devoir être inlinée, LTCG ou pas. Et le fait que la fonction est utilisée en complément de macro, je ne vois pas le rapport...

Merci koala51. Je t'applaudis, je ne sais pas comment tu fais pour trouver le temps et la patience de répondre autant dans les détails à chaque fois. :ccool:

Citation:

---

Envoyé par Matthieu Brucher

Rien n'oblige cette fonction à devoir être inlinée, LTCG ou pas. Et le fait que la fonction est utilisée en complément de macro, je ne vois pas le rapport...

---

Je retire ce que j'ai dit concernant les macros.

Mais le fait reste que si tu veux que certaines fonctions soient inlinées quand le compilateur le décide, il ne faut pas oublier les barrières qui l'empêchent. Si tu veux que l'optimisation traverse ces barrières, définir ces fonctions dans les headers (et donc, les déclarer static (sale!) ou inline (fait pour)) devient indispensable.

Citation:

---

Envoyé par Médinoc

Mais le fait reste que si tu veux que certaines fonctions soient inlinées quand le compilateur le décide, il ne faut pas oublier les barrières qui l'empêchent. Si tu veux que l'optimisation traverse ces barrières, définir ces fonctions dans les headers (et donc, les déclarer static (sale!) ou inline (fait pour)) devient indispensable.

---

Ou encore mieux, bien concevoir son architecture de code.
C'est une problématique que je connais bien car le code qu'on a ici peut potentiellement facilement avoir ce souci (et je ne parle pas naturellement qu'en C++, mais aussi en Fortran où inline n'existe pas). On arrive toujours à restructurer son code correctement de sorte à ne plus avoir ce problème.

inline et extern/static c'est orthogonal.
Une fonction inline non static est tout de même extern, c'est juste qu'elle a un linkage "faible" (i.e. l'éditeur de liens se fiche d'avoir plusieurs définitions, il va considérer qu'elles sont toutes les mêmes)

Citation:

---

Envoyé par Matthieu Brucher

Ou encore mieux, bien concevoir son architecture de code.
C'est une problématique que je connais bien car le code qu'on a ici peut potentiellement facilement avoir ce souci (et je ne parle pas naturellement qu'en C++, mais aussi en Fortran où inline n'existe pas). On arrive toujours à restructurer son code correctement de sorte à ne plus avoir ce problème.

---

Donc, tu soutiens qu'il est toujours possible d'avoir un projet où aucun composant ne propose à un autre composant de service qu'il serait plus approprié d'inliner (genre, un bête accesseur en lecture) ?

@loufoque: En théorie. Mais ça ne change rien au fait qu'un appel traversant une "frontière" (unité de compilation quand la LTCG est désactivée, bibliothèques autrement) ne sera pas inliné.