depuis que je programme en C++, je n'ai pas eu beaucoup l'occasion de
développer des templates. Je comprends bien leur usage dans les classes
de la STL que j'utilise et j'ai aussi eu l'occasion de developper des
templates similaires. Mais je me demande comment les templates
s'inscrivent dans le processus d'abstraction du langage et notamment
dans le processus d'héritage : faire dériver une classe d'un template,
ou un template d'une classe par exemple (besoin, interet, avantages,
inconvénients...). Connaissez vous des pointeurs ou références qui
pourraient m'aider à comprendre cela ?
Merci et bonne journée,
Yann
--
Yann Renard - To send me an email, remove no-spam sectionS :)
Mais les avis divergent, beauté artistique selon l'un, usine à gaz ou complexe pétro-chimique selon les autres.
La beauté d'un code réside dans sa simplicité.
C'est subjectif -- Mais tu as le droit de préférer les filles sans maquillage :-)
Si une technique avancée rend un code plus facile à comprendre, alors elle est positive.
Je ne suis que partiellement d'accord.
- Si une technique avancée rend un code plus facile à comprendre, alors elle marque quelques points.
- Si une technique avancée rend l'implémentation plus aisée, alors elle marque quelques points.
- Si une technique avancée n'est pas compréhensible pour les collègues, alors elle perds quelques points.
- etc.
-- Fab
fabien.chene.nospam
Gabriel Dos Reis writes:
(Fabien CHÊNE) writes:
| Gabriel Dos Reis writes: | | > | En fait, le langage template du C++ est turing complete, donc tu peux | > | theoriquement tout faire avec. | > | > Une question est si cela est souhaitable dans un programme non-jouet. | | Des techniques de méta-programmation (genre manipulation tordue de | mpl::list pour générer des variants),
si je dois écrire aujourd'hui du code à moyenne ou longue durée de vie, la dernière chose dont j'ai envie c'est que le maintainer soit « clever » pour le comprendre. [Note que le maintainer peut être moi-même, deux ans après :-(]
Allez, je te relance :-) : considères-tu qu'il faudra être « clever » pour émuler la méta-programmation à l'aide de concepts C++0X et de surcharges ?
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > | En fait, le langage template du C++ est turing complete, donc tu peux
| > | theoriquement tout faire avec.
| >
| > Une question est si cela est souhaitable dans un programme non-jouet.
|
| Des techniques de méta-programmation (genre manipulation tordue de
| mpl::list pour générer des variants),
si je dois écrire aujourd'hui du code à moyenne ou longue durée de
vie, la dernière chose dont j'ai envie c'est que le maintainer soit
« clever » pour le comprendre.
[Note que le maintainer peut être moi-même, deux ans après :-(]
Allez, je te relance :-) : considères-tu qu'il faudra être « clever »
pour émuler la méta-programmation à l'aide de concepts C++0X et de
surcharges ?
| Gabriel Dos Reis writes: | | > | En fait, le langage template du C++ est turing complete, donc tu peux | > | theoriquement tout faire avec. | > | > Une question est si cela est souhaitable dans un programme non-jouet. | | Des techniques de méta-programmation (genre manipulation tordue de | mpl::list pour générer des variants),
si je dois écrire aujourd'hui du code à moyenne ou longue durée de vie, la dernière chose dont j'ai envie c'est que le maintainer soit « clever » pour le comprendre. [Note que le maintainer peut être moi-même, deux ans après :-(]
Allez, je te relance :-) : considères-tu qu'il faudra être « clever » pour émuler la méta-programmation à l'aide de concepts C++0X et de surcharges ?
-- Fab
Fred
Yann Renard wrote:
Bonjour à tous,
depuis que je programme en C++, je n'ai pas eu beaucoup l'occasion de développer des templates. Je comprends bien leur usage dans les classes de la STL que j'utilise et j'ai aussi eu l'occasion de developper des templates similaires. Mais je me demande comment les templates s'inscrivent dans le processus d'abstraction du langage et notamment dans le processus d'héritage : faire dériver une classe d'un template, ou un template d'une classe par exemple (besoin, interet, avantages, inconvénients...). Connaissez vous des pointeurs ou références qui pourraient m'aider à comprendre cela ?
Merci et bonne journée, Yann
Hello,
En dehors d'Andrei, déjà cité, me vient à l'esprit la librairie Spirit de Boost (http://www.boost.org/libs/spirit/index.html), un générateur de parseurs qui utilise templates et surcharge d'opérateurs pour générer à la compile, et qui montre à quel point on peut torturer le language pour arriver à quelque chose d'utile.
Fred
Yann Renard wrote:
Bonjour à tous,
depuis que je programme en C++, je n'ai pas eu beaucoup l'occasion de
développer des templates. Je comprends bien leur usage dans les classes
de la STL que j'utilise et j'ai aussi eu l'occasion de developper des
templates similaires. Mais je me demande comment les templates
s'inscrivent dans le processus d'abstraction du langage et notamment
dans le processus d'héritage : faire dériver une classe d'un template,
ou un template d'une classe par exemple (besoin, interet, avantages,
inconvénients...). Connaissez vous des pointeurs ou références qui
pourraient m'aider à comprendre cela ?
Merci et bonne journée,
Yann
Hello,
En dehors d'Andrei, déjà cité, me vient à l'esprit la librairie Spirit
de Boost (http://www.boost.org/libs/spirit/index.html), un générateur de
parseurs qui utilise templates et surcharge d'opérateurs pour générer à
la compile, et qui montre à quel point on peut torturer le language pour
arriver à quelque chose d'utile.
depuis que je programme en C++, je n'ai pas eu beaucoup l'occasion de développer des templates. Je comprends bien leur usage dans les classes de la STL que j'utilise et j'ai aussi eu l'occasion de developper des templates similaires. Mais je me demande comment les templates s'inscrivent dans le processus d'abstraction du langage et notamment dans le processus d'héritage : faire dériver une classe d'un template, ou un template d'une classe par exemple (besoin, interet, avantages, inconvénients...). Connaissez vous des pointeurs ou références qui pourraient m'aider à comprendre cela ?
Merci et bonne journée, Yann
Hello,
En dehors d'Andrei, déjà cité, me vient à l'esprit la librairie Spirit de Boost (http://www.boost.org/libs/spirit/index.html), un générateur de parseurs qui utilise templates et surcharge d'opérateurs pour générer à la compile, et qui montre à quel point on peut torturer le language pour arriver à quelque chose d'utile.
Fred
fabien.chene.nospam
Gabriel Dos Reis writes:
(Fabien CHÊNE) writes:
| Fabien LE LEZ writes: | | >>Mais les avis divergent, beauté | >>artistique selon l'un, usine à gaz ou complexe pétro-chimique selon | >>les autres. | > | > La beauté d'un code réside dans sa simplicité. | | C'est subjectif -- Mais tu as le droit de préférer les filles sans | maquillage :-)
?
Que *je* trouve souvent beau, un code inutilement complexe mais ingénieux. Quand à la métaphore, elle était peut-être ni réussie, ni à ton goût, tant pis.
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| Fabien LE LEZ <gramster@gramster.com> writes:
|
| >>Mais les avis divergent, beauté
| >>artistique selon l'un, usine à gaz ou complexe pétro-chimique selon
| >>les autres.
| >
| > La beauté d'un code réside dans sa simplicité.
|
| C'est subjectif -- Mais tu as le droit de préférer les filles sans
| maquillage :-)
?
Que *je* trouve souvent beau, un code inutilement complexe mais
ingénieux. Quand à la métaphore, elle était peut-être ni réussie, ni à
ton goût, tant pis.
| Fabien LE LEZ writes: | | >>Mais les avis divergent, beauté | >>artistique selon l'un, usine à gaz ou complexe pétro-chimique selon | >>les autres. | > | > La beauté d'un code réside dans sa simplicité. | | C'est subjectif -- Mais tu as le droit de préférer les filles sans | maquillage :-)
?
Que *je* trouve souvent beau, un code inutilement complexe mais ingénieux. Quand à la métaphore, elle était peut-être ni réussie, ni à ton goût, tant pis.
-- Fab
kanze
Fabien CHÊNE wrote:
Fabien LE LEZ writes:
Mais les avis divergent, beauté artistique selon l'un, usine à gaz ou complexe pétro-chimique selon les autres.
La beauté d'un code réside dans sa simplicité.
C'est subjectif -- Mais tu as le droit de préférer les filles sans maquillage :-)
Quand la fille est vraiment belle, je la préfère nue -- sans maquillage ni vêtements.
Si une technique avancée rend un code plus facile à comprendre, alors elle est positive.
Je ne suis que partiellement d'accord.
- Si une technique avancée rend un code plus facile à comprendre, al ors elle marque quelques points.
- Si une technique avancée rend l'implémentation plus aisée, alors elle marque quelques points.
- Si une technique avancée n'est pas compréhensible pour les collègues, alors elle perds quelques points.
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
-- 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
Fabien CHÊNE wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Mais les avis divergent, beauté artistique selon l'un, usine
à gaz ou complexe pétro-chimique selon les autres.
La beauté d'un code réside dans sa simplicité.
C'est subjectif -- Mais tu as le droit de préférer les filles
sans maquillage :-)
Quand la fille est vraiment belle, je la préfère nue -- sans
maquillage ni vêtements.
Si une technique avancée rend un code plus facile à
comprendre, alors elle est positive.
Je ne suis que partiellement d'accord.
- Si une technique avancée rend un code plus facile à comprendre, al ors
elle marque quelques points.
- Si une technique avancée rend l'implémentation plus aisée, alors
elle marque quelques points.
- Si une technique avancée n'est pas compréhensible pour les
collègues, alors elle perds quelques points.
Si une technique (avancée ou non) rend le code incompréhensible
aux collègues, ce n'est pas qu'elle perd quelques points ; c'est
qu'on n'a même pas le droit de s'en servir.
--
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
Mais les avis divergent, beauté artistique selon l'un, usine à gaz ou complexe pétro-chimique selon les autres.
La beauté d'un code réside dans sa simplicité.
C'est subjectif -- Mais tu as le droit de préférer les filles sans maquillage :-)
Quand la fille est vraiment belle, je la préfère nue -- sans maquillage ni vêtements.
Si une technique avancée rend un code plus facile à comprendre, alors elle est positive.
Je ne suis que partiellement d'accord.
- Si une technique avancée rend un code plus facile à comprendre, al ors elle marque quelques points.
- Si une technique avancée rend l'implémentation plus aisée, alors elle marque quelques points.
- Si une technique avancée n'est pas compréhensible pour les collègues, alors elle perds quelques points.
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
-- 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
François-Xavier GENDRIN
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
il faut de tout, il faut que les plus "ingénieux" rabaissent le niveau de leur code pour que tout le monde le comprenne, mais il faut aussi que les moins "ingénieux" se penche sur le code pour le comprendre. Sinon on s'en sort pas ! -- FX
Si une technique (avancée ou non) rend le code incompréhensible
aux collègues, ce n'est pas qu'elle perd quelques points ; c'est
qu'on n'a même pas le droit de s'en servir.
il faut de tout, il faut que les plus "ingénieux" rabaissent le niveau
de leur code pour que tout le monde le comprenne, mais il faut aussi que
les moins "ingénieux" se penche sur le code pour le comprendre. Sinon on
s'en sort pas !
--
FX
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
il faut de tout, il faut que les plus "ingénieux" rabaissent le niveau de leur code pour que tout le monde le comprenne, mais il faut aussi que les moins "ingénieux" se penche sur le code pour le comprendre. Sinon on s'en sort pas ! -- FX
Yann Renard
Yann Renard wrote:
Bonjour à tous,
depuis que je programme en C++, je n'ai pas eu beaucoup l'occasion de développer des templates. Je comprends bien leur usage dans les classes de la STL que j'utilise et j'ai aussi eu l'occasion de developper des templates similaires. Mais je me demande comment les templates s'inscrivent dans le processus d'abstraction du langage et notamment dans le processus d'héritage : faire dériver une classe d'un template, ou un template d'une classe par exemple (besoin, interet, avantages, inconvénients...). Connaissez vous des pointeurs ou références qui pourraient m'aider à comprendre cela ?
Merci et bonne journée, Yann
Bonjour à tous,
merci pour vos multiples réponses. J'ai commencé à rechercher les ouvrages suggerés :
"Modern C++ Design", de Andrei Alexandrescu "C++ template, the complete guide" de Vandevoorde et Josuttis "Scientific and engineering C++" de Barton et Nackmann Ouvrages de Dave Abraham
Ces ouvrages existent ils en pdf ou ne sont ils qu'accessible "physiquement" et à la vente ?
Merci et bonne journée, Yann -- Yann Renard - To send me an email, remove no-spam sectionS :)
Yann Renard wrote:
Bonjour à tous,
depuis que je programme en C++, je n'ai pas eu beaucoup l'occasion de
développer des templates. Je comprends bien leur usage dans les classes
de la STL que j'utilise et j'ai aussi eu l'occasion de developper des
templates similaires. Mais je me demande comment les templates
s'inscrivent dans le processus d'abstraction du langage et notamment
dans le processus d'héritage : faire dériver une classe d'un template,
ou un template d'une classe par exemple (besoin, interet, avantages,
inconvénients...). Connaissez vous des pointeurs ou références qui
pourraient m'aider à comprendre cela ?
Merci et bonne journée,
Yann
Bonjour à tous,
merci pour vos multiples réponses. J'ai commencé à rechercher les
ouvrages suggerés :
"Modern C++ Design", de Andrei Alexandrescu
"C++ template, the complete guide" de Vandevoorde et Josuttis
"Scientific and engineering C++" de Barton et Nackmann
Ouvrages de Dave Abraham
Ces ouvrages existent ils en pdf ou ne sont ils qu'accessible
"physiquement" et à la vente ?
Merci et bonne journée,
Yann
--
Yann Renard - To send me an email, remove no-spam sectionS :)
depuis que je programme en C++, je n'ai pas eu beaucoup l'occasion de développer des templates. Je comprends bien leur usage dans les classes de la STL que j'utilise et j'ai aussi eu l'occasion de developper des templates similaires. Mais je me demande comment les templates s'inscrivent dans le processus d'abstraction du langage et notamment dans le processus d'héritage : faire dériver une classe d'un template, ou un template d'une classe par exemple (besoin, interet, avantages, inconvénients...). Connaissez vous des pointeurs ou références qui pourraient m'aider à comprendre cela ?
Merci et bonne journée, Yann
Bonjour à tous,
merci pour vos multiples réponses. J'ai commencé à rechercher les ouvrages suggerés :
"Modern C++ Design", de Andrei Alexandrescu "C++ template, the complete guide" de Vandevoorde et Josuttis "Scientific and engineering C++" de Barton et Nackmann Ouvrages de Dave Abraham
Ces ouvrages existent ils en pdf ou ne sont ils qu'accessible "physiquement" et à la vente ?
Merci et bonne journée, Yann -- Yann Renard - To send me an email, remove no-spam sectionS :)
fabien.chene.nospam
"kanze" writes:
Si une technique avancée rend un code plus facile à comprendre, alors elle est positive.
Je ne suis que partiellement d'accord.
- Si une technique avancée rend un code plus facile à comprendre, alors elle marque quelques points.
- Si une technique avancée rend l'implémentation plus aisée, alors elle marque quelques points.
- Si une technique avancée n'est pas compréhensible pour les collègues, alors elle perds quelques points.
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
La valeur des "quelques" est en effet à pondérer selon les situations. Il me parait tout à fait concevable qu'il y ait une pondération importante pour la compréhensibilité du code.
Il y a peut-être aussi une alternative. Expliquer la dite technique aux collègues, et voir s'il est envisageable de s'en servir.
-- Fab
"kanze" <kanze@gabi-soft.fr> writes:
Si une technique avancée rend un code plus facile à
comprendre, alors elle est positive.
Je ne suis que partiellement d'accord.
- Si une technique avancée rend un code plus facile à comprendre, alors
elle marque quelques points.
- Si une technique avancée rend l'implémentation plus aisée, alors
elle marque quelques points.
- Si une technique avancée n'est pas compréhensible pour les
collègues, alors elle perds quelques points.
Si une technique (avancée ou non) rend le code incompréhensible
aux collègues, ce n'est pas qu'elle perd quelques points ; c'est
qu'on n'a même pas le droit de s'en servir.
La valeur des "quelques" est en effet à pondérer selon les
situations. Il me parait tout à fait concevable qu'il y ait une
pondération importante pour la compréhensibilité du code.
Il y a peut-être aussi une alternative. Expliquer la dite technique
aux collègues, et voir s'il est envisageable de s'en servir.
Si une technique avancée rend un code plus facile à comprendre, alors elle est positive.
Je ne suis que partiellement d'accord.
- Si une technique avancée rend un code plus facile à comprendre, alors elle marque quelques points.
- Si une technique avancée rend l'implémentation plus aisée, alors elle marque quelques points.
- Si une technique avancée n'est pas compréhensible pour les collègues, alors elle perds quelques points.
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
La valeur des "quelques" est en effet à pondérer selon les situations. Il me parait tout à fait concevable qu'il y ait une pondération importante pour la compréhensibilité du code.
Il y a peut-être aussi une alternative. Expliquer la dite technique aux collègues, et voir s'il est envisageable de s'en servir.
-- Fab
fabien.chene.nospam
"kanze" writes:
Il n'y a pas qu'Andrei qui a traité le problème -- Dave Abraham aussi (mais je ne l'ai pas encore lu),
Si tu parles bien de Dave Abrahams en tant que co-auteur de _C++ template metaprogramming_, c'est un livre qui suppose acquise la généricité, et qui traite de la métaprogrammation. C'est aussi une visite guidée de Boost.MPL, plutôt fascinent !
-- Fab
"kanze" <kanze@gabi-soft.fr> writes:
Il n'y a pas qu'Andrei qui a traité le problème -- Dave Abraham
aussi (mais je ne l'ai pas encore lu),
Si tu parles bien de Dave Abrahams en tant que co-auteur de _C++
template metaprogramming_, c'est un livre qui suppose acquise la
généricité, et qui traite de la métaprogrammation. C'est aussi une
visite guidée de Boost.MPL, plutôt fascinent !
Il n'y a pas qu'Andrei qui a traité le problème -- Dave Abraham aussi (mais je ne l'ai pas encore lu),
Si tu parles bien de Dave Abrahams en tant que co-auteur de _C++ template metaprogramming_, c'est un livre qui suppose acquise la généricité, et qui traite de la métaprogrammation. C'est aussi une visite guidée de Boost.MPL, plutôt fascinent !
-- Fab
Jean-Marc Bourguet
François-Xavier GENDRIN writes:
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
il faut de tout, il faut que les plus "ingénieux" rabaissent le niveau de leur code pour que tout le monde le comprenne, mais il faut aussi que les moins "ingénieux" se penche sur le code pour le comprendre. Sinon on s'en sort pas !
Les programmeurs sont comme les chauffeurs, ils sont 80% à se croire au dessus de la médiane... Et la moitié des autres le sont réellement.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Si une technique (avancée ou non) rend le code incompréhensible
aux collègues, ce n'est pas qu'elle perd quelques points ; c'est
qu'on n'a même pas le droit de s'en servir.
il faut de tout, il faut que les plus "ingénieux"
rabaissent le niveau de leur code pour que tout le monde
le comprenne, mais il faut aussi que les moins "ingénieux"
se penche sur le code pour le comprendre. Sinon on s'en
sort pas !
Les programmeurs sont comme les chauffeurs, ils sont 80% à
se croire au dessus de la médiane... Et la moitié des
autres le sont réellement.
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Si une technique (avancée ou non) rend le code incompréhensible aux collègues, ce n'est pas qu'elle perd quelques points ; c'est qu'on n'a même pas le droit de s'en servir.
il faut de tout, il faut que les plus "ingénieux" rabaissent le niveau de leur code pour que tout le monde le comprenne, mais il faut aussi que les moins "ingénieux" se penche sur le code pour le comprendre. Sinon on s'en sort pas !
Les programmeurs sont comme les chauffeurs, ils sont 80% à se croire au dessus de la médiane... Et la moitié des autres le sont réellement.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
