Bonjour
 
J'aurais trois questions concernant les fonctions inline:
 
1) Est-ce que j'ai bon si j'ai compris que le mot clé "inline" devant une fonction est juste une indication pour le compilateur qui peut décider en dernier lieu de l'utiliser (càd dir "d'inligner" la fonction) ou pas et donc de la considérer comme une fonction normale ? Si oui est-ce qu'on peut quand même influencer le compilateur ? par exemple par des switches d'optimisation ?
 
2) Si dans une boucle parcourue plusieurs dizaines de milliers de fois (ou même plusieurs centaines de milliers de fois) j'appelle un certain nombre de fonctions (principalement des setX et getX), est-ce que je vais vraiment gagner en performance en mettant ces fonctions "inline" ?
 
3) Question plus philosophique vu que je suis le seul à bidouiller mon code, est-ce qu'il est possible de déclarer une fonction inline et néanmoins de cacher son implémentation ? Parce qu'à priori, pour compiler le fichier utilisant les inline je n'ai que le ".h" à disposition, alors je ne vois pas trop ou mettre cette déclaration ailleurs.
 
D'avance merci de vos explications

1) dans tous les cas que j'ai rencontrés (principalement avec gcc), le mot clé inline  est effectivement juste une indication, et est en pratique souvent ignoré par le compilateur (ça dépend des compilateurs et des niveaux d'optimisation). Je crois que gcc fournit des attributs spécifiques grâce auxquels tu peux lui spécifier que tu veux que la fonction soit toujours inlinée, quel que soit le niveau d'optimisation.
2) ca dépend, trop d'inlining peut finir par faire baisser les perfs en produisant un code trop gros. Tu devrais peut-être laisser faire ton compilateur (qui saura sans doute bien mieux que toi s'il faut inliner les getX/setX), puis profiler ton code pour voir où tu as réellement besoin d'optimiser.
3) pas à ma connaissance

inline == the BAD !
 
C'est de l'optimisation à la petite semaine

 
Ca sent le vécu ...    
des vrais raisons ?

En ce qui concerne GCC il a en effet plusieurs options pour l'inlining, et notamment: limite de taux d'inflation d'une fonction dû à l'inlining, limite de taux d'inflation du programme dû à l'inlining.
 
En forçant à la compilation, et sur un gros programme, une limite de taux d'inflation irraisonnable tu peux te trouver dans le cas où le compilateur se met à utiliser plusieurs Go de RAM.
 
Le mot-clé inline est tout de même interessant, même si tout ce qui est dans une classe est suceptible d'être inliné, car il prévient le lecteur qu'une partie de code est critique au niveau performance.
 
C'est le cas d'un get et d'un set par exemple, ces fonctions sont toujours inlinées si elles ne sont pas trop grosses.
 
Le compilateur inline les petites fonctions d'abord, les grosses ensuite, et s'arrête quand le taux d'inflation limite est atteint. GCC possède une option -Winline qui prévient quand il ne peut inliner une fonction. Utile pour vérifier.
 
> C'est de l'optimisation à la petite semaine
je dirais plutôt que c'est le B.A. BA.

 
Yep ... je suis passé sur un projet avec des fonctions inline à outrance d'ou :
- bloat (binaire obése )
- temps de compile énorme
- debug merdique : essaye de mettre un breakpoint dans une fct inline
 
Le pire est que le compilo peut décider tout seul et en général mieux que le dev moyen ce qui doit être inline  
 
En règle générale les pb d'optimisation se resolvent à la fin pas au debut.
Comment déterminer les points à optimiser avant d'avoir exécuté au moins une fois une appli ???
=> un profiler n'est pas qu'une série télé c'est aussi un outil de travail pour un codeur
 
 
 
Ps n n'a jamais fait plus rapide que du code pas éxecuté
 

Oops!
 
C'est bien ce que je disais,  
- bloat (binaire obése )
- temps de compile énorme
Exact. C'est pourquoi il faut un peu d'expérience quand même, et jouer avec les flags du compilo ça peut aider à trouver ses limites.
 
- debug merdique : essaye de mettre un breakpoint dans une fct inline  
Idem. Bien que les compilos aient fait des progrès. Au final si tu ne fait pas une compil de debug il n'y a pas de breakpoint.
 
L'optimisation ce n'est pas de mettre des inlines partout. Encore faut-il que:
- avec les options par défaut le compilo fasse du code raisonnable,
- avec des options customisées le compilo soit capable de faire un code plus compact et plus rapide.
 
> En règle générale les pb d'optimisation se resolvent à la fin pas au debut.
Oops, grave erreure. Tu confond optimisation et profiling. Les optimisations se conçoivent dès le début: va donc fait un moteur de recherche qui ai pour algo:

PS: lit le manuel d'aide de ton compilo, avant de l'utiliser!

strip est ton ami.
 

Ca vient surtotu des shcémas d'include moisiplsu que de l'inlining
 

mon gdb 4.0.1 y arrive très bien.
 

Oula ca ça dépend
 

Ou pas Dans le cas de code de calcul scientifique, il y a un minimum  
syndicale à optimisé en amont. Par contre, et le je te l'accorde, c'ets pas en balancant 15 inline
au pif qu'on va y gagner. ** pub cachée pour sa signatrue **

 
Heuuu ... je part du principe que le dev moyen utilise la partie bon sens de son cerveau c'est sur que si il decide de faire un super tri bulle sur 2 million de lignes il part pas vainqueur !
 
On n'est plus dans ce cas dans un pb d'optimisation mais plutôt d'architecture IMO.
 

heu ... pas dispo sous VC6
de plus il me semblais que le propre d'une fct inline était de ne pas générer de symbole ...
Mais j'peux me gourrager
 

Mon VC6 refuse d'envisager de penser que c'est possible
 
 

 
C'est dans le contexte du "je met du inline car ça va booster" que je me place

tu me fait douter maintenant ...
 

dis donc et Visual C++ 2005 Express Edition c'est pour les poulpes unijambistes
 

On ets bien d'accord.

 
J'ai pas le choix    
 
C'est l'env de dev sur cette mission

Faut leur dire que VC6 ne permet pas de développer en c++

vu le code que je maintient c'est déja le cas

Merci à tous pour vos réponses (qui ne me plaisent que moyennement ).
 
Comme je dois utiliser 2 compilateurs (gcc 3.3.5 sous Linux et celui se trouvant dans Visual C++), il faudra que je voie comment faire des "optimisations" compatibles.
 
leonhard