Utilisez vous les fonctions inline ?
Si oui comment ?
Le compilateur peut il faire le choix à ma place?
Bref comment faites vous, que preferez vous ?
1)
class C
{
int f(){return 0;}
}
Là le compilateur doit pouvoir faire ce qu'il veut.
2)
class C
{
inline int f(){return 0;}
}
Dans ce cas je force le inline.
3)
class C
{
int f();
}
inline int C::f(){return 0;}
Ici aussi.
4)
/**** .h ******/
class C
{
/* inline ? */ int f();
}
/*** .cpp *******/
int C::f(){return 0;}
Le compilateur peut il faire du inline dans ce cas? je vois mal comment.
"JBB" a écrit dans le message de news: 437b65f6$0$24277$
Utilisez vous les fonctions inline ? non
Si oui comment ? Le compilateur peut il faire le choix à ma place? Certainement. En fait ca dépend toujours des options d'optimisation que tu
spécifies. Des compilateurs comme VC++ .net édition standard ne permettent pas d'optimiser par contre. Il faut la version pro.
Bref comment faites vous, que preferez vous ? Je laisse le compilateur faire
En mode debug, je ne fait pas d'optimisation, mais en release oui.
1) class C { int f(){return 0;} } Là le compilateur doit pouvoir faire ce qu'il veut.
Du code dans un .h est forcément inline si je ne me trompe pas. Donc dans ce cas je crois que le mot inline est inutile
2) class C { inline int f(){return 0;} } Dans ce cas je force le inline. 3) class C { int f(); } inline int C::f(){return 0;} Ici aussi.
4) /**** .h ******/ class C { /* inline ? */ int f(); } /*** .cpp *******/ int C::f(){return 0;} Le compilateur peut il faire du inline dans ce cas? je vois mal comment.
"JBB" <merci@pasdespam.fr> a écrit dans le message de news:
437b65f6$0$24277$626a14ce@news.free.fr...
Utilisez vous les fonctions inline ?
non
Si oui comment ?
Le compilateur peut il faire le choix à ma place?
Certainement. En fait ca dépend toujours des options d'optimisation que tu
spécifies.
Des compilateurs comme VC++ .net édition standard ne permettent pas
d'optimiser par contre.
Il faut la version pro.
Bref comment faites vous, que preferez vous ?
Je laisse le compilateur faire
En mode debug, je ne fait pas d'optimisation, mais en release oui.
1)
class C
{
int f(){return 0;}
}
Là le compilateur doit pouvoir faire ce qu'il veut.
Du code dans un .h est forcément inline si je ne me trompe pas. Donc dans ce
cas je crois que
le mot inline est inutile
2)
class C
{
inline int f(){return 0;}
}
Dans ce cas je force le inline.
3)
class C
{
int f();
}
inline int C::f(){return 0;}
Ici aussi.
4)
/**** .h ******/
class C
{
/* inline ? */ int f();
}
/*** .cpp *******/
int C::f(){return 0;}
Le compilateur peut il faire du inline dans ce cas? je vois mal comment.
"JBB" a écrit dans le message de news: 437b65f6$0$24277$
Utilisez vous les fonctions inline ? non
Si oui comment ? Le compilateur peut il faire le choix à ma place? Certainement. En fait ca dépend toujours des options d'optimisation que tu
spécifies. Des compilateurs comme VC++ .net édition standard ne permettent pas d'optimiser par contre. Il faut la version pro.
Bref comment faites vous, que preferez vous ? Je laisse le compilateur faire
En mode debug, je ne fait pas d'optimisation, mais en release oui.
1) class C { int f(){return 0;} } Là le compilateur doit pouvoir faire ce qu'il veut.
Du code dans un .h est forcément inline si je ne me trompe pas. Donc dans ce cas je crois que le mot inline est inutile
2) class C { inline int f(){return 0;} } Dans ce cas je force le inline. 3) class C { int f(); } inline int C::f(){return 0;} Ici aussi.
4) /**** .h ******/ class C { /* inline ? */ int f(); } /*** .cpp *******/ int C::f(){return 0;} Le compilateur peut il faire du inline dans ce cas? je vois mal comment.
kanze
JBB wrote:
Utilisez vous les fonctions inline ?
Seulement quand le profiler dit qu'il faut.
Je peux imaginer des cas, surtout dans des bibliothèques de base, où on anticiperait le profiler -- si j'implémentais une bibliothèque standard, je ne crois pas que j'attendrais le profiler pour rendre vector::operator[] inline. Mais ces cas ne me concernent pas dans mes applications actuelles.
Si oui comment ?
Comment ça, comment ? Je mets la définition dans un fichier d'en-tête (séparé de celui qu'inclut l'utilisateur, évidemment, mais inclu par celui-là), et je mets le mot clé inline devant la définition.
Le compilateur peut il faire le choix à ma place?
Le compilateur peut toujours faire ce qu'il veut, pourvu qu'il ne change pas la sémantique du programme (et le fait qu'une fonction soit inline ou non n'a aucun effet sur la sémantique). En ce concerne la génération du code, le mot clé « inline » est un « hint » au compilateur, rien de plus. Un compilateur vraiment pervers pourrait générer inline que des fonctions non déclarées inline.
Dans la pratique, aujourd'hui, il existe des technologies de point où le compilateur, en fonction des données du profileur, peut réelement faire un meilleur choix que le programmeur, et génère du code plus rapide en ignorant complètement les tuyaux donnés par inline. Mais de telles technologies ne sont pas (encore ?) très répandues ; dans un compilateur « courant », je m'entendrais à ce que le compilateur suit mes conseils dans la mesure du possible. Avec l'exception près que s'il voit que générer le code en ligne prend moins de place qu'appeler la fonction, il pourrait bien le faire, inline ou non.
Si jamais ces technologies de point deviennent courantes, inline deviendra aussi caduc que register l'est aujourd'hui. Mais on en est encore loin, je crois -- elles sont extrèmement gourmandes en ressources machines, avec une complexité superlinéaire (exponentielle, peut-être ?) par rapport à la taille du programme.
Bref comment faites vous, que preferez vous ?
1) class C { int f(){return 0;} } Là le compilateur doit pouvoir faire ce qu'il veut.
Le compilateur peut toujours faire ce qu'il veut. Mais toutes les règles de programmation que j'ai vues interdisent la définition des fonctions dans la définition de la classe.
class C { inline int f(){return 0;} } Dans ce cas je force le inline.
On ne peut pas forcer le inline -- le compilateur fait ce qu'il veut. Mais de point de vue du langage, il n'y a aucune différence entre celui-ci et le précédant. Une définition d'une fonction dans une classe, c'est exactement comme si tu l'avais déclarer inline. (Puisque le compilateur fait ce qu'il veut, évidemment, il pourrait faire une distinction. De même qu'il pourrait faire une distinction sur le nom -- générer inline les fonctions dont le nom commence par une minuscule, par exemple. Mais ce n'est pas l'intention de la norme, et je ne connais pas de compilateur aussi pervers.)
3) class C { int f(); } inline int C::f(){return 0;} Ici aussi.
C'est ce qui se fait en général. Sauf que la définition se trouve dans un autre fichier (.tcc, .ihh...), inclu par le .hh/.hpp que voit le client. (Dans mes propres projets, je garde même ces deux fichiers dans des répertoires distincts.)
4) /**** .h ******/ class C { /* inline ? */ int f(); } /*** .cpp *******/ int C::f(){return 0;} Le compilateur peut il faire du inline dans ce cas?
Bien sûr.
je vois mal comment.
C'est son problème, pas le tien:-). En fait, la solution la plus courante, c'est d'utiliser un espèce de « byte code » à la Java dans les fichiers dits « objet », et de ne générer le code machine réel que lors de l'édition des liens. Mais d'autres solutions sont envisagables.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
JBB wrote:
Utilisez vous les fonctions inline ?
Seulement quand le profiler dit qu'il faut.
Je peux imaginer des cas, surtout dans des bibliothèques de
base, où on anticiperait le profiler -- si j'implémentais une
bibliothèque standard, je ne crois pas que j'attendrais le
profiler pour rendre vector::operator[] inline. Mais ces cas ne
me concernent pas dans mes applications actuelles.
Si oui comment ?
Comment ça, comment ? Je mets la définition dans un fichier
d'en-tête (séparé de celui qu'inclut l'utilisateur, évidemment,
mais inclu par celui-là), et je mets le mot clé inline devant la
définition.
Le compilateur peut il faire le choix à ma place?
Le compilateur peut toujours faire ce qu'il veut, pourvu qu'il
ne change pas la sémantique du programme (et le fait qu'une
fonction soit inline ou non n'a aucun effet sur la sémantique).
En ce concerne la génération du code, le mot clé « inline » est
un « hint » au compilateur, rien de plus. Un compilateur
vraiment pervers pourrait générer inline que des fonctions non
déclarées inline.
Dans la pratique, aujourd'hui, il existe des technologies de
point où le compilateur, en fonction des données du profileur,
peut réelement faire un meilleur choix que le programmeur, et
génère du code plus rapide en ignorant complètement les tuyaux
donnés par inline. Mais de telles technologies ne sont pas
(encore ?) très répandues ; dans un compilateur « courant », je
m'entendrais à ce que le compilateur suit mes conseils dans la
mesure du possible. Avec l'exception près que s'il voit que
générer le code en ligne prend moins de place qu'appeler la
fonction, il pourrait bien le faire, inline ou non.
Si jamais ces technologies de point deviennent courantes, inline
deviendra aussi caduc que register l'est aujourd'hui. Mais on en
est encore loin, je crois -- elles sont extrèmement gourmandes
en ressources machines, avec une complexité superlinéaire
(exponentielle, peut-être ?) par rapport à la taille du
programme.
Bref comment faites vous, que preferez vous ?
1)
class C
{
int f(){return 0;}
}
Là le compilateur doit pouvoir faire ce qu'il veut.
Le compilateur peut toujours faire ce qu'il veut. Mais toutes
les règles de programmation que j'ai vues interdisent la
définition des fonctions dans la définition de la classe.
class C
{
inline int f(){return 0;}
}
Dans ce cas je force le inline.
On ne peut pas forcer le inline -- le compilateur fait ce qu'il
veut. Mais de point de vue du langage, il n'y a aucune
différence entre celui-ci et le précédant. Une définition d'une
fonction dans une classe, c'est exactement comme si tu l'avais
déclarer inline. (Puisque le compilateur fait ce qu'il veut,
évidemment, il pourrait faire une distinction. De même qu'il
pourrait faire une distinction sur le nom -- générer inline les
fonctions dont le nom commence par une minuscule, par exemple.
Mais ce n'est pas l'intention de la norme, et je ne connais pas
de compilateur aussi pervers.)
3)
class C
{
int f();
}
inline int C::f(){return 0;}
Ici aussi.
C'est ce qui se fait en général. Sauf que la définition se
trouve dans un autre fichier (.tcc, .ihh...), inclu par le
.hh/.hpp que voit le client. (Dans mes propres projets, je garde
même ces deux fichiers dans des répertoires distincts.)
4)
/**** .h ******/
class C
{
/* inline ? */ int f();
}
/*** .cpp *******/
int C::f(){return 0;}
Le compilateur peut il faire du inline dans ce cas?
Bien sûr.
je vois mal comment.
C'est son problème, pas le tien:-). En fait, la solution la plus
courante, c'est d'utiliser un espèce de « byte code » à la Java
dans les fichiers dits « objet », et de ne générer le code
machine réel que lors de l'édition des liens. Mais d'autres
solutions sont envisagables.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je peux imaginer des cas, surtout dans des bibliothèques de base, où on anticiperait le profiler -- si j'implémentais une bibliothèque standard, je ne crois pas que j'attendrais le profiler pour rendre vector::operator[] inline. Mais ces cas ne me concernent pas dans mes applications actuelles.
Si oui comment ?
Comment ça, comment ? Je mets la définition dans un fichier d'en-tête (séparé de celui qu'inclut l'utilisateur, évidemment, mais inclu par celui-là), et je mets le mot clé inline devant la définition.
Le compilateur peut il faire le choix à ma place?
Le compilateur peut toujours faire ce qu'il veut, pourvu qu'il ne change pas la sémantique du programme (et le fait qu'une fonction soit inline ou non n'a aucun effet sur la sémantique). En ce concerne la génération du code, le mot clé « inline » est un « hint » au compilateur, rien de plus. Un compilateur vraiment pervers pourrait générer inline que des fonctions non déclarées inline.
Dans la pratique, aujourd'hui, il existe des technologies de point où le compilateur, en fonction des données du profileur, peut réelement faire un meilleur choix que le programmeur, et génère du code plus rapide en ignorant complètement les tuyaux donnés par inline. Mais de telles technologies ne sont pas (encore ?) très répandues ; dans un compilateur « courant », je m'entendrais à ce que le compilateur suit mes conseils dans la mesure du possible. Avec l'exception près que s'il voit que générer le code en ligne prend moins de place qu'appeler la fonction, il pourrait bien le faire, inline ou non.
Si jamais ces technologies de point deviennent courantes, inline deviendra aussi caduc que register l'est aujourd'hui. Mais on en est encore loin, je crois -- elles sont extrèmement gourmandes en ressources machines, avec une complexité superlinéaire (exponentielle, peut-être ?) par rapport à la taille du programme.
Bref comment faites vous, que preferez vous ?
1) class C { int f(){return 0;} } Là le compilateur doit pouvoir faire ce qu'il veut.
Le compilateur peut toujours faire ce qu'il veut. Mais toutes les règles de programmation que j'ai vues interdisent la définition des fonctions dans la définition de la classe.
class C { inline int f(){return 0;} } Dans ce cas je force le inline.
On ne peut pas forcer le inline -- le compilateur fait ce qu'il veut. Mais de point de vue du langage, il n'y a aucune différence entre celui-ci et le précédant. Une définition d'une fonction dans une classe, c'est exactement comme si tu l'avais déclarer inline. (Puisque le compilateur fait ce qu'il veut, évidemment, il pourrait faire une distinction. De même qu'il pourrait faire une distinction sur le nom -- générer inline les fonctions dont le nom commence par une minuscule, par exemple. Mais ce n'est pas l'intention de la norme, et je ne connais pas de compilateur aussi pervers.)
3) class C { int f(); } inline int C::f(){return 0;} Ici aussi.
C'est ce qui se fait en général. Sauf que la définition se trouve dans un autre fichier (.tcc, .ihh...), inclu par le .hh/.hpp que voit le client. (Dans mes propres projets, je garde même ces deux fichiers dans des répertoires distincts.)
4) /**** .h ******/ class C { /* inline ? */ int f(); } /*** .cpp *******/ int C::f(){return 0;} Le compilateur peut il faire du inline dans ce cas?
Bien sûr.
je vois mal comment.
C'est son problème, pas le tien:-). En fait, la solution la plus courante, c'est d'utiliser un espèce de « byte code » à la Java dans les fichiers dits « objet », et de ne générer le code machine réel que lors de l'édition des liens. Mais d'autres solutions sont envisagables.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Aurelien Regat-Barrel
Des compilateurs comme VC++ .net édition standard ne permettent pas d'optimiser par contre. Il faut la version pro.
Ou simplement la version gratuite "vc++ 2003 toolkit", ou la nouvelle version gratuite VC++ Express.
Le compilateur peut il faire du inline dans ce cas? je vois mal comment.
Avec VC++, y'a l'option optimisation globale "whole program optimisation" http://gilles-vollant.developpez.com/visual-cpp/optimisation/
En gros, la première phase de compilation est incomplète, et le linker rappelle ensuite le compilateur pour la terminer.
-- Aurélien Regat-Barrel
Des compilateurs comme VC++ .net édition standard ne permettent pas
d'optimiser par contre.
Il faut la version pro.
Ou simplement la version gratuite "vc++ 2003 toolkit", ou la nouvelle
version gratuite VC++ Express.
Le compilateur peut il faire du inline dans ce cas? je vois mal comment.
Avec VC++, y'a l'option optimisation globale "whole program optimisation"
http://gilles-vollant.developpez.com/visual-cpp/optimisation/
En gros, la première phase de compilation est incomplète, et le linker
rappelle ensuite le compilateur pour la terminer.