Attention cependant (en C++ notamment) a ne pas tomber dans l'exces qui consiste a mettre du inline partout !
En effet, l'inline brise le principe d'encapsulation (un concept important de l'approche objet) qui veut que le code des methodes soit cach'e a l'utilisateur. De plus, il faut savoir utiliser le inline a bon escient. Si la methode fait une ligne de code, ca passe. Si elle en fait 20, la passer inline va rendre difficile la lecture du fichier d'entete !
Avant de se dire "ouais, je vais foutre du inline partout, ca va etre putain d'optimis'e", il est bon de deceler les goulots d'etranglement de l'application afin de cibler l'optimisation. En effet, il ne sert a rien de gagner qques 10emes de sec sur une partie du code quand une autre prend 2 secondes a s'executer !
Enfin, il faut savoir que dans la mesure du possible, le compilateur se charge de passer des methodes inlines lorsqu'on l'appelle avec l'option d'optimisation.
[^] # Re: Complement d'infos...
Posté par Thibauld Favre . En réponse à la dépêche Java 1.4.0 releas candidate. Évalué à 2.
En effet, l'inline brise le principe d'encapsulation (un concept important de l'approche objet) qui veut que le code des methodes soit cach'e a l'utilisateur. De plus, il faut savoir utiliser le inline a bon escient. Si la methode fait une ligne de code, ca passe. Si elle en fait 20, la passer inline va rendre difficile la lecture du fichier d'entete !
Avant de se dire "ouais, je vais foutre du inline partout, ca va etre putain d'optimis'e", il est bon de deceler les goulots d'etranglement de l'application afin de cibler l'optimisation. En effet, il ne sert a rien de gagner qques 10emes de sec sur une partie du code quand une autre prend 2 secondes a s'executer !
Enfin, il faut savoir que dans la mesure du possible, le compilateur se charge de passer des methodes inlines lorsqu'on l'appelle avec l'option d'optimisation.
Voila.. rien que l'info mais toute (?) l'info ;)