Compilation Firewall: avantages sans trop d'inconvenient ?
14 réponses
Marc Boyer
Bon, dans la série "je découvre la vie", je repensais à l'idiome
Pimpl. Si j'ai tout bien compris:
- avantages:
* recompilation accélérée (indépendante de l'implémentation)
* possibilité de faire évoluer des librairies (puisqu'on a
pas à recompiler le code utilisateur)
- inconvénients:
* petit surcrois de code à écrire
* une indirection de plus à chaque accès
Hors, il me semble qu'on pourrait avoir un truc qui offre un
avanage sur deux en suprimant un inconvénient sur deux en
distinguant un mode "en développement" et un mode "optimisé".
Suffirait d'envelopper le pointeur pimpl dans une classe
qui soit un simple pointeur en mode développement (recompilation
rapide), et qui contienne vraiment l'objet en mode
optimisé.
C'est tellement évident que personne n'a trouvé intéressant
de le mentionner ou il y a un truc que j'ai raté ?
Jusqu'à là, pas de problème. Mais comment fait tu pour organiser ton fichier d'en-tête ?
Ben... On peut imaginer des solutions à base de #ifdef ou d'option -I. J'aurais une préférence pour l'option -I, avec un répertoire decl/, dans lequel on a le Pimpl classique, et chaque fichier MaClasseImpl.hpp ne contient que la ligne class MaClasseImpl; qui suffit à compiler le code utilisateur en Pimpl classique, et un répertoire def/ dans lequel on a le faux Pimpl, et les fichiers MaClasseImpl.hpp qui contiennent la déclaration complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué pour peu de chose. En gros, tant que le profiler n'en indique pas le besoin, ce n'est pas la peine. Et quand il l'indique, il faut penser que souvent, tu vas vouloir mettre un certain nombre de fonctions membre en ligne aussi, ce qui complique ta solution encore plus.
Pour l'instant, c'est une idée intéressante, mais je ne crois pas qu'elle rapporte assez par rapport à l'effort nécessaire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<bpkjeo$ot1$1@news.cict.fr>...
kanze@gabi-soft.fr wrote:
[...]
Jusqu'à là, pas de problème. Mais comment fait tu pour organiser ton
fichier d'en-tête ?
Ben... On peut imaginer des solutions à base de #ifdef ou
d'option -I.
J'aurais une préférence pour l'option -I, avec un répertoire
decl/, dans lequel on a le Pimpl classique, et chaque fichier
MaClasseImpl.hpp ne contient que la ligne
class MaClasseImpl;
qui suffit à compiler le code utilisateur en Pimpl classique,
et un répertoire def/ dans lequel on a le faux Pimpl, et
les fichiers MaClasseImpl.hpp qui contiennent la déclaration
complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué
pour peu de chose. En gros, tant que le profiler n'en indique pas le
besoin, ce n'est pas la peine. Et quand il l'indique, il faut penser que
souvent, tu vas vouloir mettre un certain nombre de fonctions membre en
ligne aussi, ce qui complique ta solution encore plus.
Pour l'instant, c'est une idée intéressante, mais je ne crois pas
qu'elle rapporte assez par rapport à l'effort nécessaire.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Jusqu'à là, pas de problème. Mais comment fait tu pour organiser ton fichier d'en-tête ?
Ben... On peut imaginer des solutions à base de #ifdef ou d'option -I. J'aurais une préférence pour l'option -I, avec un répertoire decl/, dans lequel on a le Pimpl classique, et chaque fichier MaClasseImpl.hpp ne contient que la ligne class MaClasseImpl; qui suffit à compiler le code utilisateur en Pimpl classique, et un répertoire def/ dans lequel on a le faux Pimpl, et les fichiers MaClasseImpl.hpp qui contiennent la déclaration complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué pour peu de chose. En gros, tant que le profiler n'en indique pas le besoin, ce n'est pas la peine. Et quand il l'indique, il faut penser que souvent, tu vas vouloir mettre un certain nombre de fonctions membre en ligne aussi, ce qui complique ta solution encore plus.
Pour l'instant, c'est une idée intéressante, mais je ne crois pas qu'elle rapporte assez par rapport à l'effort nécessaire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer
wrote:
J'aurais une préférence pour l'option -I, avec un répertoire decl/, dans lequel on a le Pimpl classique, et chaque fichier MaClasseImpl.hpp ne contient que la ligne class MaClasseImpl; qui suffit à compiler le code utilisateur en Pimpl classique, et un répertoire def/ dans lequel on a le faux Pimpl, et les fichiers MaClasseImpl.hpp qui contiennent la déclaration complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué pour peu de chose. En gros, tant que le profiler n'en indique pas le besoin, ce n'est pas la peine.
Tout à fait.
Et quand il l'indique, il faut penser que souvent, tu vas vouloir mettre un certain nombre de fonctions membre en ligne aussi, ce qui complique ta solution encore plus.
Je pense que la mise inline des fonctions du firewall doit pouvoir se faire dans la définition de la classe sans difficulté int foo(float f){ return impl.foo(f); } et la mise inline des fonctions de l'objet manipulé doit pouvoir se faire de la même façon que pour d'autres, non ?
Pour l'instant, c'est une idée intéressante, mais je ne crois pas qu'elle rapporte assez par rapport à l'effort nécessaire.
C'est tout à fait possible. Déjà, le bénéfice du Pimpl est purement théorique pour moi puisque les codes sur lesquels je travaille ne me posent pas de problème de temps de compil. J'avais juste repéré que, dans la plupart des présentations de l'idiome que j'ai lues, l'indirection suplémentaire était présentée comme un inconvéniant de par son coût. C'est le problème de l'enseignant: essayer de comprendre les problèmes, enjeux et solutions d'un milieu qui n'est pas le sien.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze@gabi-soft.fr wrote:
J'aurais une préférence pour l'option -I, avec un répertoire
decl/, dans lequel on a le Pimpl classique, et chaque fichier
MaClasseImpl.hpp ne contient que la ligne
class MaClasseImpl;
qui suffit à compiler le code utilisateur en Pimpl classique,
et un répertoire def/ dans lequel on a le faux Pimpl, et
les fichiers MaClasseImpl.hpp qui contiennent la déclaration
complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué
pour peu de chose. En gros, tant que le profiler n'en indique pas le
besoin, ce n'est pas la peine.
Tout à fait.
Et quand il l'indique, il faut penser que
souvent, tu vas vouloir mettre un certain nombre de fonctions membre en
ligne aussi, ce qui complique ta solution encore plus.
Je pense que la mise inline des fonctions du firewall doit
pouvoir se faire dans la définition de la classe sans
difficulté
int foo(float f){ return impl.foo(f); }
et la mise inline des fonctions de l'objet manipulé doit
pouvoir se faire de la même façon que pour d'autres, non ?
Pour l'instant, c'est une idée intéressante, mais je ne crois pas
qu'elle rapporte assez par rapport à l'effort nécessaire.
C'est tout à fait possible. Déjà, le bénéfice du Pimpl est
purement théorique pour moi puisque les codes sur lesquels
je travaille ne me posent pas de problème de temps de compil.
J'avais juste repéré que, dans la plupart des présentations
de l'idiome que j'ai lues, l'indirection suplémentaire
était présentée comme un inconvéniant de par son coût.
C'est le problème de l'enseignant: essayer de comprendre
les problèmes, enjeux et solutions d'un milieu qui n'est
pas le sien.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
J'aurais une préférence pour l'option -I, avec un répertoire decl/, dans lequel on a le Pimpl classique, et chaque fichier MaClasseImpl.hpp ne contient que la ligne class MaClasseImpl; qui suffit à compiler le code utilisateur en Pimpl classique, et un répertoire def/ dans lequel on a le faux Pimpl, et les fichiers MaClasseImpl.hpp qui contiennent la déclaration complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué pour peu de chose. En gros, tant que le profiler n'en indique pas le besoin, ce n'est pas la peine.
Tout à fait.
Et quand il l'indique, il faut penser que souvent, tu vas vouloir mettre un certain nombre de fonctions membre en ligne aussi, ce qui complique ta solution encore plus.
Je pense que la mise inline des fonctions du firewall doit pouvoir se faire dans la définition de la classe sans difficulté int foo(float f){ return impl.foo(f); } et la mise inline des fonctions de l'objet manipulé doit pouvoir se faire de la même façon que pour d'autres, non ?
Pour l'instant, c'est une idée intéressante, mais je ne crois pas qu'elle rapporte assez par rapport à l'effort nécessaire.
C'est tout à fait possible. Déjà, le bénéfice du Pimpl est purement théorique pour moi puisque les codes sur lesquels je travaille ne me posent pas de problème de temps de compil. J'avais juste repéré que, dans la plupart des présentations de l'idiome que j'ai lues, l'indirection suplémentaire était présentée comme un inconvéniant de par son coût. C'est le problème de l'enseignant: essayer de comprendre les problèmes, enjeux et solutions d'un milieu qui n'est pas le sien.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze
Marc Boyer wrote in message news:<bpse0k$ar9$...
wrote:
J'aurais une préférence pour l'option -I, avec un répertoire decl/, dans lequel on a le Pimpl classique, et chaque fichier MaClasseImpl.hpp ne contient que la ligne class MaClasseImpl; qui suffit à compiler le code utilisateur en Pimpl classique, et un répertoire def/ dans lequel on a le faux Pimpl, et les fichiers MaClasseImpl.hpp qui contiennent la déclaration complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué pour peu de chose. En gros, tant que le profiler n'en indique pas le besoin, ce n'est pas la peine.
Tout à fait.
Et quand il l'indique, il faut penser que souvent, tu vas vouloir mettre un certain nombre de fonctions membre en ligne aussi, ce qui complique ta solution encore plus.
Je pense que la mise inline des fonctions du firewall doit pouvoir se faire dans la définition de la classe sans difficulté int foo(float f){ return impl.foo(f); } et la mise inline des fonctions de l'objet manipulé doit pouvoir se faire de la même façon que pour d'autres, non ?
Ça veut dire que le compilateur sache que impl a une fonction foo dans l'en-tête. Je ne vois pas où il pourrait le savoir sans que la classe cachée soit visible.
Pour l'instant, c'est une idée intéressante, mais je ne crois pas qu'elle rapporte assez par rapport à l'effort nécessaire.
C'est tout à fait possible. Déjà, le bénéfice du Pimpl est purement théorique pour moi puisque les codes sur lesquels je travaille ne me posent pas de problème de temps de compil.
Si c'est le cas, et que la nature de l'application est telle qu'elle ne risque pas d'arriver à une taille où ça pose un problème, il n'y a pas de raison à se compliquer la vie avec l'idiome du firewall. Ce n'a pas été mon expérience, dans les projets où j'ai travaillé dans la passée. Mais c'est vrai que c'est le cas actuellement, et en fait, je me sers assez peu de l'idiome actuellement.
J'avais juste repéré que, dans la plupart des présentations de l'idiome que j'ai lues, l'indirection suplémentaire était présentée comme un inconvéniant de par son coût.
Certes. Disons que il y a deux coûts supplémentaire : l'indirection, et l'allocation. Le premier est petit, mais touche à chaque appel de fonction, et empêche la mise en ligne. Le deuxième peut être rélativement cher, mais ne concerne que la création et la destruction.
D'après mon expérience : on n'utilise pas le firewall sur des objets petits et simple, et qui risque être créés et detruit souvent. D'une part, ça ne vaut pas la peine, puisque de tels objets n'ont pas beaucoup de dépendences, et de l'autre, le prix n'est pas négligeable. En revanche, même des objets gros et complexes ont souvent quelques fonctions simples -- dans ces cas-là, tant pis. On paie le prix, parce que c'est faible pour chaque appel, et si par la suite il s'avère être un problème, on laisse tomber le firewall pour la classe en question.
C'est le problème de l'enseignant: essayer de comprendre les problèmes, enjeux et solutions d'un milieu qui n'est pas le sien.
C'est effectivement un problème. Heureusement, il y a des enseignants qui s'y rendent compte, et cherche à y faire quelque chose.
L'alternatif, ça serait de prendre des gars de l'industrie pour faire de l'enseignement. Malheureusement, je n'en connais pas, moi-même compris, qui en serait capable. Enseigner, c'est un métier en soi.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<bpse0k$ar9$1@news.cict.fr>...
kanze@gabi-soft.fr wrote:
J'aurais une préférence pour l'option -I, avec un répertoire
decl/, dans lequel on a le Pimpl classique, et chaque fichier
MaClasseImpl.hpp ne contient que la ligne
class MaClasseImpl;
qui suffit à compiler le code utilisateur en Pimpl classique,
et un répertoire def/ dans lequel on a le faux Pimpl, et
les fichiers MaClasseImpl.hpp qui contiennent la déclaration
complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien
compliqué pour peu de chose. En gros, tant que le profiler n'en
indique pas le besoin, ce n'est pas la peine.
Tout à fait.
Et quand il l'indique, il faut penser que souvent, tu vas vouloir
mettre un certain nombre de fonctions membre en ligne aussi, ce qui
complique ta solution encore plus.
Je pense que la mise inline des fonctions du firewall doit
pouvoir se faire dans la définition de la classe sans
difficulté
int foo(float f){ return impl.foo(f); }
et la mise inline des fonctions de l'objet manipulé doit
pouvoir se faire de la même façon que pour d'autres, non ?
Ça veut dire que le compilateur sache que impl a une fonction foo dans
l'en-tête. Je ne vois pas où il pourrait le savoir sans que la classe
cachée soit visible.
Pour l'instant, c'est une idée intéressante, mais je ne crois pas
qu'elle rapporte assez par rapport à l'effort nécessaire.
C'est tout à fait possible. Déjà, le bénéfice du Pimpl est
purement théorique pour moi puisque les codes sur lesquels
je travaille ne me posent pas de problème de temps de compil.
Si c'est le cas, et que la nature de l'application est telle qu'elle ne
risque pas d'arriver à une taille où ça pose un problème, il n'y a pas
de raison à se compliquer la vie avec l'idiome du firewall. Ce n'a pas
été mon expérience, dans les projets où j'ai travaillé dans la passée.
Mais c'est vrai que c'est le cas actuellement, et en fait, je me sers
assez peu de l'idiome actuellement.
J'avais juste repéré que, dans la plupart des présentations
de l'idiome que j'ai lues, l'indirection suplémentaire
était présentée comme un inconvéniant de par son coût.
Certes. Disons que il y a deux coûts supplémentaire : l'indirection, et
l'allocation. Le premier est petit, mais touche à chaque appel de
fonction, et empêche la mise en ligne. Le deuxième peut être
rélativement cher, mais ne concerne que la création et la destruction.
D'après mon expérience : on n'utilise pas le firewall sur des objets
petits et simple, et qui risque être créés et detruit souvent. D'une
part, ça ne vaut pas la peine, puisque de tels objets n'ont pas beaucoup
de dépendences, et de l'autre, le prix n'est pas négligeable. En
revanche, même des objets gros et complexes ont souvent quelques
fonctions simples -- dans ces cas-là, tant pis. On paie le prix, parce
que c'est faible pour chaque appel, et si par la suite il s'avère être
un problème, on laisse tomber le firewall pour la classe en question.
C'est le problème de l'enseignant: essayer de comprendre
les problèmes, enjeux et solutions d'un milieu qui n'est
pas le sien.
C'est effectivement un problème. Heureusement, il y a des enseignants
qui s'y rendent compte, et cherche à y faire quelque chose.
L'alternatif, ça serait de prendre des gars de l'industrie pour faire de
l'enseignement. Malheureusement, je n'en connais pas, moi-même compris,
qui en serait capable. Enseigner, c'est un métier en soi.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
J'aurais une préférence pour l'option -I, avec un répertoire decl/, dans lequel on a le Pimpl classique, et chaque fichier MaClasseImpl.hpp ne contient que la ligne class MaClasseImpl; qui suffit à compiler le code utilisateur en Pimpl classique, et un répertoire def/ dans lequel on a le faux Pimpl, et les fichiers MaClasseImpl.hpp qui contiennent la déclaration complète, tout ça.
C'est un peu ce que j'avais imaginé, mais ça me semble bien compliqué pour peu de chose. En gros, tant que le profiler n'en indique pas le besoin, ce n'est pas la peine.
Tout à fait.
Et quand il l'indique, il faut penser que souvent, tu vas vouloir mettre un certain nombre de fonctions membre en ligne aussi, ce qui complique ta solution encore plus.
Je pense que la mise inline des fonctions du firewall doit pouvoir se faire dans la définition de la classe sans difficulté int foo(float f){ return impl.foo(f); } et la mise inline des fonctions de l'objet manipulé doit pouvoir se faire de la même façon que pour d'autres, non ?
Ça veut dire que le compilateur sache que impl a une fonction foo dans l'en-tête. Je ne vois pas où il pourrait le savoir sans que la classe cachée soit visible.
Pour l'instant, c'est une idée intéressante, mais je ne crois pas qu'elle rapporte assez par rapport à l'effort nécessaire.
C'est tout à fait possible. Déjà, le bénéfice du Pimpl est purement théorique pour moi puisque les codes sur lesquels je travaille ne me posent pas de problème de temps de compil.
Si c'est le cas, et que la nature de l'application est telle qu'elle ne risque pas d'arriver à une taille où ça pose un problème, il n'y a pas de raison à se compliquer la vie avec l'idiome du firewall. Ce n'a pas été mon expérience, dans les projets où j'ai travaillé dans la passée. Mais c'est vrai que c'est le cas actuellement, et en fait, je me sers assez peu de l'idiome actuellement.
J'avais juste repéré que, dans la plupart des présentations de l'idiome que j'ai lues, l'indirection suplémentaire était présentée comme un inconvéniant de par son coût.
Certes. Disons que il y a deux coûts supplémentaire : l'indirection, et l'allocation. Le premier est petit, mais touche à chaque appel de fonction, et empêche la mise en ligne. Le deuxième peut être rélativement cher, mais ne concerne que la création et la destruction.
D'après mon expérience : on n'utilise pas le firewall sur des objets petits et simple, et qui risque être créés et detruit souvent. D'une part, ça ne vaut pas la peine, puisque de tels objets n'ont pas beaucoup de dépendences, et de l'autre, le prix n'est pas négligeable. En revanche, même des objets gros et complexes ont souvent quelques fonctions simples -- dans ces cas-là, tant pis. On paie le prix, parce que c'est faible pour chaque appel, et si par la suite il s'avère être un problème, on laisse tomber le firewall pour la classe en question.
C'est le problème de l'enseignant: essayer de comprendre les problèmes, enjeux et solutions d'un milieu qui n'est pas le sien.
C'est effectivement un problème. Heureusement, il y a des enseignants qui s'y rendent compte, et cherche à y faire quelque chose.
L'alternatif, ça serait de prendre des gars de l'industrie pour faire de l'enseignement. Malheureusement, je n'en connais pas, moi-même compris, qui en serait capable. Enseigner, c'est un métier en soi.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer
wrote:
Marc Boyer wrote in message
Je pense que la mise inline des fonctions du firewall doit pouvoir se faire dans la définition de la classe sans difficulté int foo(float f){ return impl.foo(f); } et la mise inline des fonctions de l'objet manipulé doit pouvoir se faire de la même façon que pour d'autres, non ?
Ça veut dire que le compilateur sache que impl a une fonction foo dans l'en-tête. Je ne vois pas où il pourrait le savoir sans que la classe cachée soit visible.
Oui, j'avais raté une étape. Ca peut se résoudre avec un fichier ".ipp" (inline) vide dans le répertoire decl/ et avec le code dans impl/, mais ça rajoute encore une couche de complexité.
J'avais juste repéré que, dans la plupart des présentations de l'idiome que j'ai lues, l'indirection suplémentaire était présentée comme un inconvéniant de par son coût.
Certes. Disons que il y a deux coûts supplémentaire : l'indirection, et l'allocation. Le premier est petit, mais touche à chaque appel de fonction, et empêche la mise en ligne. Le deuxième peut être rélativement cher, mais ne concerne que la création et la destruction.
OK
D'après mon expérience : on n'utilise pas le firewall sur des objets petits et simple, et qui risque être créés et detruit souvent. D'une part, ça ne vaut pas la peine, puisque de tels objets n'ont pas beaucoup de dépendences, et de l'autre, le prix n'est pas négligeable. En revanche, même des objets gros et complexes ont souvent quelques fonctions simples -- dans ces cas-là, tant pis. On paie le prix, parce que c'est faible pour chaque appel, et si par la suite il s'avère être un problème, on laisse tomber le firewall pour la classe en question.
OK
C'est le problème de l'enseignant: essayer de comprendre les problèmes, enjeux et solutions d'un milieu qui n'est pas le sien.
C'est effectivement un problème. Heureusement, il y a des enseignants qui s'y rendent compte, et cherche à y faire quelque chose.
Heureusement qu'il y a fclc++ ;-)
L'alternatif, ça serait de prendre des gars de l'industrie pour faire de l'enseignement. Malheureusement, je n'en connais pas, moi-même compris, qui en serait capable. Enseigner, c'est un métier en soi.
En France, il existe des status qui permettent de faire ça. On en utilise quelques uns.
Tous les experts ne sont pas de bons enseignants, et réciproquement. L'autre alternative, ce serait de permettre aux enseignants de passer de temps en temps une année dans le privé. Mais c'est statutairement pas gagné.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
Je pense que la mise inline des fonctions du firewall doit
pouvoir se faire dans la définition de la classe sans
difficulté
int foo(float f){ return impl.foo(f); }
et la mise inline des fonctions de l'objet manipulé doit
pouvoir se faire de la même façon que pour d'autres, non ?
Ça veut dire que le compilateur sache que impl a une fonction foo dans
l'en-tête. Je ne vois pas où il pourrait le savoir sans que la classe
cachée soit visible.
Oui, j'avais raté une étape. Ca peut se résoudre avec un
fichier ".ipp" (inline) vide dans le répertoire decl/ et
avec le code dans impl/, mais ça rajoute encore une
couche de complexité.
J'avais juste repéré que, dans la plupart des présentations
de l'idiome que j'ai lues, l'indirection suplémentaire
était présentée comme un inconvéniant de par son coût.
Certes. Disons que il y a deux coûts supplémentaire : l'indirection, et
l'allocation. Le premier est petit, mais touche à chaque appel de
fonction, et empêche la mise en ligne. Le deuxième peut être
rélativement cher, mais ne concerne que la création et la destruction.
OK
D'après mon expérience : on n'utilise pas le firewall sur des objets
petits et simple, et qui risque être créés et detruit souvent. D'une
part, ça ne vaut pas la peine, puisque de tels objets n'ont pas beaucoup
de dépendences, et de l'autre, le prix n'est pas négligeable. En
revanche, même des objets gros et complexes ont souvent quelques
fonctions simples -- dans ces cas-là, tant pis. On paie le prix, parce
que c'est faible pour chaque appel, et si par la suite il s'avère être
un problème, on laisse tomber le firewall pour la classe en question.
OK
C'est le problème de l'enseignant: essayer de comprendre
les problèmes, enjeux et solutions d'un milieu qui n'est
pas le sien.
C'est effectivement un problème. Heureusement, il y a des enseignants
qui s'y rendent compte, et cherche à y faire quelque chose.
Heureusement qu'il y a fclc++ ;-)
L'alternatif, ça serait de prendre des gars de l'industrie pour faire de
l'enseignement. Malheureusement, je n'en connais pas, moi-même compris,
qui en serait capable. Enseigner, c'est un métier en soi.
En France, il existe des status qui permettent de faire ça.
On en utilise quelques uns.
Tous les experts ne sont pas de bons enseignants, et réciproquement.
L'autre alternative, ce serait de permettre aux enseignants de passer
de temps en temps une année dans le privé. Mais c'est statutairement
pas gagné.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Je pense que la mise inline des fonctions du firewall doit pouvoir se faire dans la définition de la classe sans difficulté int foo(float f){ return impl.foo(f); } et la mise inline des fonctions de l'objet manipulé doit pouvoir se faire de la même façon que pour d'autres, non ?
Ça veut dire que le compilateur sache que impl a une fonction foo dans l'en-tête. Je ne vois pas où il pourrait le savoir sans que la classe cachée soit visible.
Oui, j'avais raté une étape. Ca peut se résoudre avec un fichier ".ipp" (inline) vide dans le répertoire decl/ et avec le code dans impl/, mais ça rajoute encore une couche de complexité.
J'avais juste repéré que, dans la plupart des présentations de l'idiome que j'ai lues, l'indirection suplémentaire était présentée comme un inconvéniant de par son coût.
Certes. Disons que il y a deux coûts supplémentaire : l'indirection, et l'allocation. Le premier est petit, mais touche à chaque appel de fonction, et empêche la mise en ligne. Le deuxième peut être rélativement cher, mais ne concerne que la création et la destruction.
OK
D'après mon expérience : on n'utilise pas le firewall sur des objets petits et simple, et qui risque être créés et detruit souvent. D'une part, ça ne vaut pas la peine, puisque de tels objets n'ont pas beaucoup de dépendences, et de l'autre, le prix n'est pas négligeable. En revanche, même des objets gros et complexes ont souvent quelques fonctions simples -- dans ces cas-là, tant pis. On paie le prix, parce que c'est faible pour chaque appel, et si par la suite il s'avère être un problème, on laisse tomber le firewall pour la classe en question.
OK
C'est le problème de l'enseignant: essayer de comprendre les problèmes, enjeux et solutions d'un milieu qui n'est pas le sien.
C'est effectivement un problème. Heureusement, il y a des enseignants qui s'y rendent compte, et cherche à y faire quelque chose.
Heureusement qu'il y a fclc++ ;-)
L'alternatif, ça serait de prendre des gars de l'industrie pour faire de l'enseignement. Malheureusement, je n'en connais pas, moi-même compris, qui en serait capable. Enseigner, c'est un métier en soi.
En France, il existe des status qui permettent de faire ça. On en utilise quelques uns.
Tous les experts ne sont pas de bons enseignants, et réciproquement. L'autre alternative, ce serait de permettre aux enseignants de passer de temps en temps une année dans le privé. Mais c'est statutairement pas gagné.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
