fonction inline

Citation:

---

Envoyé par NiamorH

Moi si, ben c'est pas joli :mrgreen:

---

Pourtant, pour reprendre un grand classique :

Code:

---

1 2 3 4

inline Singleton& get_singleton () { static Singleton s; return s; }

---

vu ce que fait la fonction, on ne risque pas de changer sa définition souvent, alors pourquoi pas inline?

Citation:

---

Envoyé par Médinoc

Ah, OK, ça dit si les variables statiques de la fonction seront dupliquées ou non.
Je dois dire que je n'ai jamais eu l'idée de mettre une variable statique dans une fonction inline...

---

Tu peux aussi comparer les adresses des fonctions static inline pour constater qu'elles sont différentes (évidemment, il faudra qu'une fonction externe renvoie cette adresse!), et vérifier que l'adresse d'une fonction extern inline est la même partout (même façon de procéder).

Mais en pratique, c'est nettement plus rare que le cas de variables statiques dans une fonction (déjà, on déclare rarement inline les fonctions dont on prend l'adresse!).

Citation:

---

Envoyé par corrector

Tu peux aussi comparer les adresses des fonctions static inline pour constater qu'elles sont différentes (évidemment, il faudra qu'une fonction externe renvoie cette adresse!),

---

???
Comment une fonction inliné peut avoir une adresses????
si elle est inline, c'est pour que la fonction soit remplacé par du code? non?

Citation:

---

Envoyé par Mongaulois

???
Comment une fonction inliné peut avoir une adresses????
si elle est inline, c'est pour que la fonction soit remplacé par du code? non?

---

En C++, une fonction inline a exactement la même sémantique qu'une fonction non-inline :

• On peut prendre son adresse.
• Si elle est implicitement ou explicitement déclarée "extern", elle est réellement externe, comme je l'ai montré avec les variables statiques (et les adresses).
• Elle peut être récursive.
• Surtout, elle a une liaison externe, donc est soumise à la "One Definition Rule" (on hop, on revient à la discussion précédente, d'où celle-ci a "bourgeonnée")

La seule différence avec une fonction non-inline est le fait de la définir dans toute UT où elle est appelée (pour que le compilateur ai une chance de la compiler en-ligne, malgré la compilation séparée).

PS : en C++, on peut aussi prendre l'adresse d'une variable locale déclarée avec en "register storage class".

Citation:

---

Envoyé par corrector

Pourtant, pour reprendre un grand classique :

Code:

---

1 2 3 4

inline Singleton& get_singleton () { static Singleton s; return s; }

---

vu ce que fait la fonction, on ne risque pas de changer sa définition souvent, alors pourquoi pas inline?

---

Salut, c'est exactement le code que j'avais écrit. Je te dis pas le bordel...

J'avais tout simplement un singleton différent dans chaque cpp qui l'utilisait. Mais le probleme ne se déclarait qu'en release, les fonctions n'étant visiblement pas inlinées lors du débug, donc j'ai mis plus d'une heure à comprendre que le probleme venait de la.. J'etais obligé de faire des messagebox à tout bout de champs, vu que je devait me mettre en release. beurk.

Citation:

---

Envoyé par NiamorH

Salut, c'est exactement le code que j'avais écrit. Je te dis pas le bordel...

J'avais tout simplement un singleton différent dans chaque cpp qui l'utilisait.

---

C'était pas avec un compilateur dont le nom commence par "V" et ne contient pas "Age", par hasard?

ouaip VC6 pour pas le dénoncer.

Citation:

---

Envoyé par Emmanuel Deloget

Citation:

---

Envoyé par Mongaulois

Salut.
Merci, de ta réponse.
Va falloir que je la relise pour bien comprendre :aie:


Pourquoi?

---

Principalement parce que le compilateur sait quel fonction lui sera utile d'inliner de manière à obtenir les performances maximales. Si on force l'inline d'une fonction trop longue, on risque de faire exploser la taille du code et de défaire certaines optimisations (notamment celles qui ont trait au cache de code).

En fait, le mot clef inline est libre d'être totalement ignoré par les compilateurs. Il peut décider de mettre en inline certaines fonctions qui ne sont pas déclarée inline, et de refuser l'inlining de certaines fonctions qui sont déclarées inline.

---

Citation:

---

Envoyé par corrector

En C++, une fonction inline a exactement la même sémantique qu'une fonction non-inline :

• On peut prendre son adresse.
• Si elle est implicitement ou explicitement déclarée "extern", elle est réellement externe, comme je l'ai montré avec les variables statiques (et les adresses).
• Elle peut être récursive.
• Surtout, elle a une liaison externe, donc est soumise à la "One Definition Rule" (on hop, on revient à la discussion précédente, d'où celle-ci a "bourgeonnée")

La seule différence avec une fonction non-inline est le fait de la définir dans toute UT où elle est appelée (pour que le compilateur ai une chance de la compiler en-ligne, malgré la compilation séparée).

PS : en C++, on peut aussi prendre l'adresse d'une variable locale déclarée avec en "register storage class".

---

La je ne comprend plus rien.... a quoi ser inline alors???

Pour la discussion, il ne faut pas confondre le mot clef inline et le fait qu'un appel de fonction spécifique soit inliné.

Le mot clef a juste l'effet indiqué par Corrector : Imposer la définition dans toutes les UT où elle est utilisée. Plus servir d'indice (totalement ignorable s'il le souhaite) pour le compilateur pour lui indiquer que mettre en place le second mécanisme pourrait ne pas être une mauvaise chose.

Le fait qu'un appel soit inliné a les conséquences classiques en terme de perf... Mais à noter que c'est un appel qui est inliné, pas une fonction. Donc on peut toujours en prendre l'adresse etc... Après, bien entendu, si le compilateur détecte que tous les appels à une fonction sont inlinés, et que l'adresse n'est jamais prise, rien ne l'empêche le compilateur de supprimer aussi la fonction, c'est sa tambouille interne.

Certains ont suggéré qu'avec les compilateur actuels, le mot clef inline devenait inutile, le compilateur étant désormais plus intelligent que le développeur pour ces choses là. Il semble qu'en pratique ce ne soit pas encore le cas tout le temps.

Citation:

---

Envoyé par JolyLoic

Le mot clef a juste l'effet indiqué par Corrector : Imposer la définition dans toutes les UT où elle est utilisée.

---

C'est comme utiliser un static ou un namespace anonyme dans un .h ???

Citation:

---

Mais à noter que c'est un appel qui est inliné,

---

C'est a dire?

Citation:

---

Envoyé par Mongaulois

C'est comme utiliser un static ou un namespace anonyme dans un .h ???

---

Pas vraiment. static ou namespace anonymes vont définir des fonctions différentes ayant (quasi) le même nom. inline va permettre de définir plusieurs fois la même fonction.

Citation:

---

Envoyé par Mongaulois

C'est a dire?

---

Dans le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void g() { f(); // 1 f(); // 2 }   void h() { g(); // 3 g(); // 4 }

---

Rien n'empêche au compilateur d'inliner l'appel de f sur la ligne 1, mais pas celui sur la ligne 2, ou toute autre combinaison. Donc on ne peut pas dire que globalement, la fonction soit inlinée ou pas, c'est une décision prise à chaque appel de fonction.

D'ailleurs, ça va même plus loin, puisque, si le compilateur décide d'inliner les appels 3 et 4, il a le droit d'inliner différemment le 1 et 2 selon qu'ils sont considérés dans le contexte de résolution de 3 ou de 4.

Commence à comprendre :king:
merci beaucoup

Citation:

---

Envoyé par JolyLoic

Certains ont suggéré qu'avec les compilateur actuels, le mot clef inline devenait inutile, le compilateur étant désormais plus intelligent que le développeur pour ces choses là. Il semble qu'en pratique ce ne soit pas encore le cas tout le temps.

---

J'attends le compilateur qui me fait de l'inline inter-unite de compilation sur les programmes sur lesquels je travaille.

(Ceci dit, il y en a qui abusent... j'ai vu une fonction inline de plus de 500 lignes)

Sous Visual en /LTCG, c'est ce qui est supposé se passer.

Citation:

---

Envoyé par JolyLoic

Certains ont suggéré qu'avec les compilateur actuels, le mot clef inline devenait inutile, le compilateur étant désormais plus intelligent que le développeur pour ces choses là. Il semble qu'en pratique ce ne soit pas encore le cas tout le temps.

---

Certains ont suggéré cela quand BS a introduit inline en C++ (C with classes?). Il semblerait que certains suggèrent cela depuis au moins 30 ans (peut-être plus?).

De toutes façons, la décision de coupler la recompilation des clients d'un module à la modification de la définition d'une fonction revient clairement au programmeur, pas au compilateur!

Ceci dit, même en mode release, quand le problème du couplage ne se pose pas, je ne crois pas qu'un compilateur pourra jamais faire mieux que le programmeur en terme d'inline. (Et je pense que la plupart - pas tous! - de ceux qui pensent le contraire n'ont pas du tout considéré la complexité du problème : si on considère que inliner = supprimer la séquence PUSH/CALL/RET, évidemment, c'est très simple.)

Personnellement, je prend cette suggestion uniquement comme un argument de plus pour ne pas passer des fonctions en inline avant d'être en phase d'optimisation, en me disant que pour 80% des fonctions à inliner, le compilateur aura fait le sale boulot lui même.

Et je dois avouer que je n'ai encore jamais eu besoin de le faire, mes phases d'optim s'arrêtant généralement aux optims d'algorithme.

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'attends le compilateur qui me fait de l'inline inter-unite de compilation sur les programmes sur lesquels je travaille.

---

Dis-nous l'ordre de grandeur!

Citation:

---

Envoyé par Jean-Marc.Bourguet

(Ceci dit, il y en a qui abusent... j'ai vu une fonction inline de plus de 500 lignes)

---

Ça dépend : si c'est juste un immense switch, et que dans le contexte de l'appelant, le compilateur peut voir quel case est sélectionné... juste pour dire que l'opportunité de compiler en-ligne dépend du contexte et n'est pas une décision simple, à faire uniquement selon la taille du corps de la fonction appelée.

(J'avais d'ailleurs vu une proposition pour un hint/"pragma" inline par appel.)

Citation:

---

Envoyé par Médinoc

Sous Visual en /LTCG, c'est ce qui est supposé se passer.

---

Un qui n'a pas compris que je ne travaille pas sous Windows.

Citation:

---

Envoyé par corrector

Dis-nous l'ordre de grandeur!

---

J'ai environ 40000 fichiers et 20000000 de lignes de code visibles. Mais je n'ai pas idee
de la quantite de code qui sont dans des bibliotheques dont je n'ai pas le code ni de ce qui est duplique.

Citation:

---

Ça dépend : si c'est juste un immense switch, et que dans le contexte de l'appelant, le compilateur peut voir quel case est sélectionné... juste pour dire que l'opportunité de compiler en-ligne dépend du contexte et n'est pas une décision simple, à faire uniquement selon la taille du corps de la fonction appelée.

---

Rien d'aussi simple.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Un qui n'a pas compris que je ne travaille pas sous Windows.

---

Je n'ai jamais sous-entendu que tu bossais sous Windows, ni que tu utilisais Visual.

Peut-être que d'autres compilateurs sont capables de retarder la génération de code jusqu'à l'édition de liens...

Citation:

---

Envoyé par Médinoc

Peut-être que d'autres compilateurs sont capables de retarder la génération de code jusqu'à l'édition de liens...

---

Le compilateur d'HP le fait depuis longtemps. Mais ca ne passe pas a l'echelle superieure.

Le probleme est d'en trouver un qui accepte mes programmes. Je ne connais que le projet de Google avec gcc (faire ca avec de gros programmes en distribuant la charge) qui a pour objectif des programmes de cet ordre de grandeur.