Template, argument par defaut et declaration en avant
35 réponses
Marc Boyer
Bonjour,
bon, je reprends un (gros) code C++, alors je vais avoir je crois pas
mal de questions.
Pour le moment, j'ai un problème de template + argument template par defaut
+ declaration en avant.
Soit une classe avec un argument template par defaut, genre
template <class T,
template <class X> cont= std::list>
class Collection {
T t;
cont<int> c;
};
J'ai besoin dans une autre classe de faire une déclaration en avant,
mais comme je ne fixe pas dans ce cas de valeur au 2ème argument
template, il faut que je fasse une déclaration en avant complète:
template <class T,
template <class X> cont= std::list>
class Collection;
Et quand je définis la classe, il rale d'une redéclaration
des arguments par défaut...
J'ai pensé à un fichier du genre
CollectionFwd.h
dans la même veine que
iosfwd
mais est-ce que je sors pas le marteau pour écraser une mouche ?
Est-ce qu'il y a des pratiques "habituelles" ?
Vous faites comment vous ?
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le moment, des hypothèses sur les « programmes raisonnablement bien écrits » :-)
Interessant. J'ai peur de ne pas avoir compris le slide 9.
Est-ce que vous avez regarde ASIS pour l'Ada (qui m'a l'air d'avoir le meme objectif et est si j'ai bonne memoire standardise; je ne sais pas s'il y a d'autres implementation de celle de Gnat).
A+
-- 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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
En ce moment, on réfléchit sur un système de module pour
« The Pivot (IPR/XPR) »
et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le
moment, des hypothèses sur les « programmes raisonnablement bien écrits
» :-)
Interessant. J'ai peur de ne pas avoir compris le slide 9.
Est-ce que vous avez regarde ASIS pour l'Ada (qui m'a l'air d'avoir le
meme objectif et est si j'ai bonne memoire standardise; je ne sais pas
s'il y a d'autres implementation de celle de Gnat).
A+
--
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
et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le moment, des hypothèses sur les « programmes raisonnablement bien écrits » :-)
Interessant. J'ai peur de ne pas avoir compris le slide 9.
Est-ce que vous avez regarde ASIS pour l'Ada (qui m'a l'air d'avoir le meme objectif et est si j'ai bonne memoire standardise; je ne sais pas s'il y a d'autres implementation de celle de Gnat).
A+
-- 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
Christophe de VIENNE
En ce moment, on réfléchit sur un système de module pour « The Pivot (IPR/XPR) »
Interessant. Je crains n'avoir pas compris le slide 9.
Avez-vous regarde ASIS pour l'Ada qui m'a l'air d'avoir le meme objectif que votre IPR. Je crois que c'est standardise mais je ne connais pas d'autre implementation que celle de Gnat.
et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le moment, des hypothèses sur les « programmes raisonnablement bien écrits » :-)
J'imagine assez bien une partie des problemes -- je sais qu'il doit y en avoir d'autres :-)
A+
-- 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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
En ce moment, on réfléchit sur un système de module pour
« The Pivot (IPR/XPR) »
Interessant. Je crains n'avoir pas compris le slide 9.
Avez-vous regarde ASIS pour l'Ada qui m'a l'air d'avoir le meme
objectif que votre IPR. Je crois que c'est standardise mais je ne
connais pas d'autre implementation que celle de Gnat.
et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le
moment, des hypothèses sur les « programmes raisonnablement bien écrits
» :-)
J'imagine assez bien une partie des problemes -- je sais qu'il doit y
en avoir d'autres :-)
A+
--
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
Interessant. Je crains n'avoir pas compris le slide 9.
Avez-vous regarde ASIS pour l'Ada qui m'a l'air d'avoir le meme objectif que votre IPR. Je crois que c'est standardise mais je ne connais pas d'autre implementation que celle de Gnat.
et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le moment, des hypothèses sur les « programmes raisonnablement bien écrits » :-)
J'imagine assez bien une partie des problemes -- je sais qu'il doit y en avoir d'autres :-)
A+
-- 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
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes: | | > En ce moment, on réfléchit sur un système de module pour | > « The Pivot (IPR/XPR) » | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | | Interessant. Je crains n'avoir pas compris le slide 9.
C'étais un machin d'une demi-heure, alors du coup c'est un peu condensé. Au slide p.9, je voulais dire que les parseurs pour XPR doivent être simples à écrire et qu'on devrait avoir la même efficacité que si on faisait un simple « cat ».
| Avez-vous regarde ASIS pour l'Ada qui m'a l'air d'avoir le meme | objectif que votre IPR. Je crois que c'est standardise mais je ne | connais pas d'autre implementation que celle de Gnat.
Intéressant, je ne l'avais pas du tout regardé. Merci du tuyau.
| > et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le | > moment, des hypothèses sur les « programmes raisonnablement bien écrits | > » :-) | | J'imagine assez bien une partie des problemes -- je sais qu'il doit y | en avoir d'autres :-)
On peut faire du calcul de préfixes et essayer de représenter les mêmes préfixes (suites de même includes) comme un module séparé. Mais que se passe-t-il si on rencontre ailleurs plusieurs fois la même suite de token
struct A { .... };
?
Pour le moment, on suppose qu'un programme « bien écrit » ne contient rien de tel, donc on aurait plusieurs classes distinctes :-)
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > En ce moment, on réfléchit sur un système de module pour
| > « The Pivot (IPR/XPR) »
| >
| > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
|
| Interessant. Je crains n'avoir pas compris le slide 9.
C'étais un machin d'une demi-heure, alors du coup c'est un peu
condensé. Au slide p.9, je voulais dire que les parseurs pour XPR
doivent être simples à écrire et qu'on devrait avoir la même efficacité
que si on faisait un simple « cat ».
| Avez-vous regarde ASIS pour l'Ada qui m'a l'air d'avoir le meme
| objectif que votre IPR. Je crois que c'est standardise mais je ne
| connais pas d'autre implementation que celle de Gnat.
Intéressant, je ne l'avais pas du tout regardé. Merci du tuyau.
| > et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le
| > moment, des hypothèses sur les « programmes raisonnablement bien écrits
| > » :-)
|
| J'imagine assez bien une partie des problemes -- je sais qu'il doit y
| en avoir d'autres :-)
On peut faire du calcul de préfixes et essayer de représenter les
mêmes préfixes (suites de même includes) comme un module séparé.
Mais que se passe-t-il si on rencontre ailleurs plusieurs fois la même
suite de token
struct A { .... };
?
Pour le moment, on suppose qu'un programme « bien écrit » ne contient
rien de tel, donc on aurait plusieurs classes distinctes :-)
| Gabriel Dos Reis writes: | | > En ce moment, on réfléchit sur un système de module pour | > « The Pivot (IPR/XPR) » | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | | Interessant. Je crains n'avoir pas compris le slide 9.
C'étais un machin d'une demi-heure, alors du coup c'est un peu condensé. Au slide p.9, je voulais dire que les parseurs pour XPR doivent être simples à écrire et qu'on devrait avoir la même efficacité que si on faisait un simple « cat ».
| Avez-vous regarde ASIS pour l'Ada qui m'a l'air d'avoir le meme | objectif que votre IPR. Je crois que c'est standardise mais je ne | connais pas d'autre implementation que celle de Gnat.
Intéressant, je ne l'avais pas du tout regardé. Merci du tuyau.
| > et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le | > moment, des hypothèses sur les « programmes raisonnablement bien écrits | > » :-) | | J'imagine assez bien une partie des problemes -- je sais qu'il doit y | en avoir d'autres :-)
On peut faire du calcul de préfixes et essayer de représenter les mêmes préfixes (suites de même includes) comme un module séparé. Mais que se passe-t-il si on rencontre ailleurs plusieurs fois la même suite de token
struct A { .... };
?
Pour le moment, on suppose qu'un programme « bien écrit » ne contient rien de tel, donc on aurait plusieurs classes distinctes :-)
-- Gaby
Gabriel Dos Reis
Christophe de VIENNE writes:
| > En ce moment, on réfléchit sur un système de module pour | > « The Pivot (IPR/XPR) » | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | > et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le | > moment, des hypothèses sur les « programmes raisonnablement bien écrits | > » :-) | | C'est super interessant comme truc. Y a-t-il plus d'information à ce | sujet quelque part ?
Très bientôt.
-- Gaby
Christophe de VIENNE <cdevienne@alphacent.com> writes:
| > En ce moment, on réfléchit sur un système de module pour
| > « The Pivot (IPR/XPR) »
| > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
| > et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le
| > moment, des hypothèses sur les « programmes raisonnablement bien écrits
| > » :-)
|
| C'est super interessant comme truc. Y a-t-il plus d'information à ce
| sujet quelque part ?
| > En ce moment, on réfléchit sur un système de module pour | > « The Pivot (IPR/XPR) » | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | > et même là, le moins qu'on puisse dire, c'est qu'on fait, pour le | > moment, des hypothèses sur les « programmes raisonnablement bien écrits | > » :-) | | C'est super interessant comme truc. Y a-t-il plus d'information à ce | sujet quelque part ?
Très bientôt.
-- Gaby
Jean-Marc Bourguet
Gabriel Dos Reis writes:
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes: | | > En ce moment, on réfléchit sur un système de module pour | > « The Pivot (IPR/XPR) » | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | | Interessant. Je crains n'avoir pas compris le slide 9.
C'étais un machin d'une demi-heure, alors du coup c'est un peu condensé. Au slide p.9, je voulais dire que les parseurs pour XPR doivent être simples à écrire et qu'on devrait avoir la même efficacité que si on faisait un simple « cat ».
Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread, mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il s'agit de l'utilisation de template cacher les implementations.
[...]
| J'imagine assez bien une partie des problemes -- je sais qu'il doit y | en avoir d'autres :-)
On peut faire du calcul de préfixes et essayer de représenter les mêmes préfixes (suites de même includes) comme un module séparé. Mais que se passe-t-il si on rencontre ailleurs plusieurs fois la même suite de token
struct A { .... };
?
Pour le moment, on suppose qu'un programme « bien écrit » ne contient rien de tel, donc on aurait plusieurs classes distinctes :-)
Je vois :-) Je me suis penche aussi sur le probleme de faire de la creation automatique de "bindings" C++ pour un langage ayant une notion de module bien definie (disons Ada par exemple).
Ou ca devient tres gai, c'est quand des gens se sont amuses a detecter que d'autres bibliotheques etaient chargees pour ajouter ou modifier les declarations d'un include.
A+
-- 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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > En ce moment, on réfléchit sur un système de module pour
| > « The Pivot (IPR/XPR) »
| >
| > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
|
| Interessant. Je crains n'avoir pas compris le slide 9.
C'étais un machin d'une demi-heure, alors du coup c'est un peu
condensé. Au slide p.9, je voulais dire que les parseurs pour XPR
doivent être simples à écrire et qu'on devrait avoir la même efficacité
que si on faisait un simple « cat ».
Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread,
mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il
s'agit de l'utilisation de template cacher les implementations.
[...]
| J'imagine assez bien une partie des problemes -- je sais qu'il doit y
| en avoir d'autres :-)
On peut faire du calcul de préfixes et essayer de représenter les
mêmes préfixes (suites de même includes) comme un module séparé.
Mais que se passe-t-il si on rencontre ailleurs plusieurs fois la même
suite de token
struct A { .... };
?
Pour le moment, on suppose qu'un programme « bien écrit » ne
contient rien de tel, donc on aurait plusieurs classes distinctes
:-)
Je vois :-) Je me suis penche aussi sur le probleme de faire de la
creation automatique de "bindings" C++ pour un langage ayant une
notion de module bien definie (disons Ada par exemple).
Ou ca devient tres gai, c'est quand des gens se sont amuses a detecter
que d'autres bibliotheques etaient chargees pour ajouter ou modifier
les declarations d'un include.
A+
--
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
| Gabriel Dos Reis writes: | | > En ce moment, on réfléchit sur un système de module pour | > « The Pivot (IPR/XPR) » | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | | Interessant. Je crains n'avoir pas compris le slide 9.
C'étais un machin d'une demi-heure, alors du coup c'est un peu condensé. Au slide p.9, je voulais dire que les parseurs pour XPR doivent être simples à écrire et qu'on devrait avoir la même efficacité que si on faisait un simple « cat ».
Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread, mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il s'agit de l'utilisation de template cacher les implementations.
[...]
| J'imagine assez bien une partie des problemes -- je sais qu'il doit y | en avoir d'autres :-)
On peut faire du calcul de préfixes et essayer de représenter les mêmes préfixes (suites de même includes) comme un module séparé. Mais que se passe-t-il si on rencontre ailleurs plusieurs fois la même suite de token
struct A { .... };
?
Pour le moment, on suppose qu'un programme « bien écrit » ne contient rien de tel, donc on aurait plusieurs classes distinctes :-)
Je vois :-) Je me suis penche aussi sur le probleme de faire de la creation automatique de "bindings" C++ pour un langage ayant une notion de module bien definie (disons Ada par exemple).
Ou ca devient tres gai, c'est quand des gens se sont amuses a detecter que d'autres bibliotheques etaient chargees pour ajouter ou modifier les declarations d'un include.
A+
-- 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
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > | Gabriel Dos Reis writes: | > | | > | > En ce moment, on réfléchit sur un système de module pour | > | > « The Pivot (IPR/XPR) » | > | > | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | > | | > | Interessant. Je crains n'avoir pas compris le slide 9. | > | > C'étais un machin d'une demi-heure, alors du coup c'est un peu | > condensé. Au slide p.9, je voulais dire que les parseurs pour XPR | > doivent être simples à écrire et qu'on devrait avoir la même efficacité | > que si on faisait un simple « cat ». | | Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread, | mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il | s'agit de l'utilisation de template cacher les implementations.
Ah, je vois.
Au départ, l'idée est qu'on sépare classe interface, de class implémentation. Donc on avait des classes du genre
struct Expr { /* class abstraite */ }; struct Decl : Decl { /*... idem */ }; struct Var : Decl { /* itoo */ };
Ce qui nous donne la sémantique qu'on voulait au départ.
[...]
| Je vois :-) Je me suis penche aussi sur le probleme de faire de la | creation automatique de "bindings" C++ pour un langage ayant une | notion de module bien definie (disons Ada par exemple). | | Ou ca devient tres gai, c'est quand des gens se sont amuses a detecter | que d'autres bibliotheques etaient chargees pour ajouter ou modifier | les declarations d'un include.
Arf :-( -- mais je présume que c'est courant :-/
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > Jean-Marc Bourguet <jm@bourguet.org> writes:
| >
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > |
| > | > En ce moment, on réfléchit sur un système de module pour
| > | > « The Pivot (IPR/XPR) »
| > | >
| > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
| > |
| > | Interessant. Je crains n'avoir pas compris le slide 9.
| >
| > C'étais un machin d'une demi-heure, alors du coup c'est un peu
| > condensé. Au slide p.9, je voulais dire que les parseurs pour XPR
| > doivent être simples à écrire et qu'on devrait avoir la même efficacité
| > que si on faisait un simple « cat ».
|
| Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread,
| mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il
| s'agit de l'utilisation de template cacher les implementations.
Ah, je vois.
Au départ, l'idée est qu'on sépare classe interface, de class
implémentation. Donc on avait des classes du genre
struct Expr { /* class abstraite */ };
struct Decl : Decl { /*... idem */ };
struct Var : Decl { /* itoo */ };
Ce qui nous donne la sémantique qu'on voulait au départ.
[...]
| Je vois :-) Je me suis penche aussi sur le probleme de faire de la
| creation automatique de "bindings" C++ pour un langage ayant une
| notion de module bien definie (disons Ada par exemple).
|
| Ou ca devient tres gai, c'est quand des gens se sont amuses a detecter
| que d'autres bibliotheques etaient chargees pour ajouter ou modifier
| les declarations d'un include.
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > | Gabriel Dos Reis writes: | > | | > | > En ce moment, on réfléchit sur un système de module pour | > | > « The Pivot (IPR/XPR) » | > | > | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | > | | > | Interessant. Je crains n'avoir pas compris le slide 9. | > | > C'étais un machin d'une demi-heure, alors du coup c'est un peu | > condensé. Au slide p.9, je voulais dire que les parseurs pour XPR | > doivent être simples à écrire et qu'on devrait avoir la même efficacité | > que si on faisait un simple « cat ». | | Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread, | mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il | s'agit de l'utilisation de template cacher les implementations.
Ah, je vois.
Au départ, l'idée est qu'on sépare classe interface, de class implémentation. Donc on avait des classes du genre
struct Expr { /* class abstraite */ }; struct Decl : Decl { /*... idem */ }; struct Var : Decl { /* itoo */ };
Ce qui nous donne la sémantique qu'on voulait au départ.
[...]
| Je vois :-) Je me suis penche aussi sur le probleme de faire de la | creation automatique de "bindings" C++ pour un langage ayant une | notion de module bien definie (disons Ada par exemple). | | Ou ca devient tres gai, c'est quand des gens se sont amuses a detecter | que d'autres bibliotheques etaient chargees pour ajouter ou modifier | les declarations d'un include.
Arf :-( -- mais je présume que c'est courant :-/
-- Gaby
Jean-Marc Bourguet
Gabriel Dos Reis writes:
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > | Gabriel Dos Reis writes: | > | | > | > En ce moment, on réfléchit sur un système de module pour | > | > « The Pivot (IPR/XPR) » | > | > | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | > | | > | Interessant. Je crains n'avoir pas compris le slide 9. | > | > C'étais un machin d'une demi-heure, alors du coup c'est un peu | > condensé. Au slide p.9, je voulais dire que les parseurs pour XPR | > doivent être simples à écrire et qu'on devrait avoir la même efficacité | > que si on faisait un simple « cat ». | | Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread, | mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il | s'agit de l'utilisation de template cacher les implementations.
Ah, je vois.
Au départ, l'idée est qu'on sépare classe interface, de class implémentation. Donc on avait des classes du genre
struct Expr { /* class abstraite */ }; struct Decl : Decl { /*... idem */ }; struct Var : Decl { /* itoo */ };
Ce qui nous donne la sémantique qu'on voulait au départ.
C'est ce que j'avais compris. Mais c'est quoi que vous utilisez pour Decl_impl? Si c'est Decl_impl<Decl>, alors Var_impl n'en est pas un et ça me gène de ne pas pouvoir passer des Var_impl où je veux des Decl_impl; ok, on peut demander des Var mais ça force à mettre des choses propres à l'implémentation dans Var (ce qui est particulièrement génant dans les cas où j'ai des impl1/impl2 qui ont besoin de choses différentes).
Si c'est Decl_impl<Var> c'est un Var et ça me gène aussi.
A+
-- 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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > Jean-Marc Bourguet <jm@bourguet.org> writes:
| >
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > |
| > | > En ce moment, on réfléchit sur un système de module pour
| > | > « The Pivot (IPR/XPR) »
| > | >
| > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
| > |
| > | Interessant. Je crains n'avoir pas compris le slide 9.
| >
| > C'étais un machin d'une demi-heure, alors du coup c'est un peu
| > condensé. Au slide p.9, je voulais dire que les parseurs pour XPR
| > doivent être simples à écrire et qu'on devrait avoir la même efficacité
| > que si on faisait un simple « cat ».
|
| Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread,
| mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il
| s'agit de l'utilisation de template cacher les implementations.
Ah, je vois.
Au départ, l'idée est qu'on sépare classe interface, de class
implémentation. Donc on avait des classes du genre
struct Expr { /* class abstraite */ };
struct Decl : Decl { /*... idem */ };
struct Var : Decl { /* itoo */ };
Ce qui nous donne la sémantique qu'on voulait au départ.
C'est ce que j'avais compris. Mais c'est quoi que vous
utilisez pour Decl_impl? Si c'est Decl_impl<Decl>, alors
Var_impl n'en est pas un et ça me gène de ne pas pouvoir
passer des Var_impl où je veux des Decl_impl; ok, on peut
demander des Var mais ça force à mettre des choses propres à
l'implémentation dans Var (ce qui est particulièrement
génant dans les cas où j'ai des impl1/impl2 qui ont besoin
de choses différentes).
Si c'est Decl_impl<Var> c'est un Var et ça me gène aussi.
A+
--
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
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > | Gabriel Dos Reis writes: | > | | > | > En ce moment, on réfléchit sur un système de module pour | > | > « The Pivot (IPR/XPR) » | > | > | > | > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf | > | | > | Interessant. Je crains n'avoir pas compris le slide 9. | > | > C'étais un machin d'une demi-heure, alors du coup c'est un peu | > condensé. Au slide p.9, je voulais dire que les parseurs pour XPR | > doivent être simples à écrire et qu'on devrait avoir la même efficacité | > que si on faisait un simple « cat ». | | Ca j'avais compris. Je faisais allusion a la page 9/17 d'acroread, | mais elle est numerotee 8 (de meme d'ailleurs que la suivante). Il | s'agit de l'utilisation de template cacher les implementations.
Ah, je vois.
Au départ, l'idée est qu'on sépare classe interface, de class implémentation. Donc on avait des classes du genre
struct Expr { /* class abstraite */ }; struct Decl : Decl { /*... idem */ }; struct Var : Decl { /* itoo */ };
Ce qui nous donne la sémantique qu'on voulait au départ.
C'est ce que j'avais compris. Mais c'est quoi que vous utilisez pour Decl_impl? Si c'est Decl_impl<Decl>, alors Var_impl n'en est pas un et ça me gène de ne pas pouvoir passer des Var_impl où je veux des Decl_impl; ok, on peut demander des Var mais ça force à mettre des choses propres à l'implémentation dans Var (ce qui est particulièrement génant dans les cas où j'ai des impl1/impl2 qui ont besoin de choses différentes).
Si c'est Decl_impl<Var> c'est un Var et ça me gène aussi.
A+
-- 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
Gabriel Dos Reis
Jean-Marc Bourguet writes:
[...]
| > On a décidé d'éliminer ces dérivations viruelles. | > Alors on a fait (grosso modo) : | > | > template<class Interface> | > struct Expr_impl : Interface { .... }; | > | > template<class Interface> | > struct Decl_impl : Expr_impl<Interface> { ... }; | > | > struct Var_impl : Decl_impl<Var> { .... }; | > | > Du coup, on a la chaine d'heritage suivante | > | > Var_impl -> Decl_impl<> -> Expr_impl -> Var -> Decl -> Expr | > | > Ce qui nous donne la sémantique qu'on voulait au départ. | | C'est ce que j'avais compris. Mais c'est quoi que vous | utilisez pour Decl_impl? Si c'est Decl_impl<Decl>, alors | Var_impl n'en est pas un et ça me gène de ne pas pouvoir | passer des Var_impl où je veux des Decl_impl;
Dans la chaîne d'instantiation, Decl_impl<> est Decl_impl<Var> ; c'est la même valeur pour "Interface" qui est propagée jusqu'en "haut".
| ok, on peut | demander des Var mais ça force à mettre des choses propres à | l'implémentation dans Var (ce qui est particulièrement | génant dans les cas où j'ai des impl1/impl2 qui ont besoin | de choses différentes).
Aucune classe abstraite ne contient de données membres. Les fonctions membres sont toutes virtuelles -- pour la plupart pure. Si tu envisages deux implémentations différentes pour Var, il n'y a pas de problème tant que les sémantiques de l'interface sont respectées.
| Si c'est Decl_impl<Var> c'est un Var et ça me gène aussi.
Là, je ne te suis pas. Pourquoi cela te gêne ? Pour la plus grande part des analyses, seules les classes interfaces sont nécessaires -- et elles ne supportent aucune opération non-const.
Là où on a besoin des classes d'implémentation, c'est quand on construit un graphe où on veut faire une opération non-const ; mais dans ces cas on opère sur Var_impl et rarement sur Decl_impl<> -- de toute façon, il n'y a pas de moyen d'avoir un Decl_impl<> par la classe de visite.
Ai-je mal compris ta question ?
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| > On a décidé d'éliminer ces dérivations viruelles.
| > Alors on a fait (grosso modo) :
| >
| > template<class Interface>
| > struct Expr_impl : Interface { .... };
| >
| > template<class Interface>
| > struct Decl_impl : Expr_impl<Interface> { ... };
| >
| > struct Var_impl : Decl_impl<Var> { .... };
| >
| > Du coup, on a la chaine d'heritage suivante
| >
| > Var_impl -> Decl_impl<> -> Expr_impl -> Var -> Decl -> Expr
| >
| > Ce qui nous donne la sémantique qu'on voulait au départ.
|
| C'est ce que j'avais compris. Mais c'est quoi que vous
| utilisez pour Decl_impl? Si c'est Decl_impl<Decl>, alors
| Var_impl n'en est pas un et ça me gène de ne pas pouvoir
| passer des Var_impl où je veux des Decl_impl;
Dans la chaîne d'instantiation, Decl_impl<> est Decl_impl<Var> ;
c'est la même valeur pour "Interface" qui est propagée jusqu'en "haut".
| ok, on peut
| demander des Var mais ça force à mettre des choses propres à
| l'implémentation dans Var (ce qui est particulièrement
| génant dans les cas où j'ai des impl1/impl2 qui ont besoin
| de choses différentes).
Aucune classe abstraite ne contient de données membres.
Les fonctions membres sont toutes virtuelles -- pour la plupart pure.
Si tu envisages deux implémentations différentes pour Var, il n'y a
pas de problème tant que les sémantiques de l'interface sont
respectées.
| Si c'est Decl_impl<Var> c'est un Var et ça me gène aussi.
Là, je ne te suis pas. Pourquoi cela te gêne ?
Pour la plus grande part des analyses, seules les classes interfaces
sont nécessaires -- et elles ne supportent aucune opération non-const.
Là où on a besoin des classes d'implémentation, c'est quand on
construit un graphe où on veut faire une opération non-const ; mais
dans ces cas on opère sur Var_impl et rarement sur Decl_impl<> -- de
toute façon, il n'y a pas de moyen d'avoir un Decl_impl<> par la
classe de visite.
| > On a décidé d'éliminer ces dérivations viruelles. | > Alors on a fait (grosso modo) : | > | > template<class Interface> | > struct Expr_impl : Interface { .... }; | > | > template<class Interface> | > struct Decl_impl : Expr_impl<Interface> { ... }; | > | > struct Var_impl : Decl_impl<Var> { .... }; | > | > Du coup, on a la chaine d'heritage suivante | > | > Var_impl -> Decl_impl<> -> Expr_impl -> Var -> Decl -> Expr | > | > Ce qui nous donne la sémantique qu'on voulait au départ. | | C'est ce que j'avais compris. Mais c'est quoi que vous | utilisez pour Decl_impl? Si c'est Decl_impl<Decl>, alors | Var_impl n'en est pas un et ça me gène de ne pas pouvoir | passer des Var_impl où je veux des Decl_impl;
Dans la chaîne d'instantiation, Decl_impl<> est Decl_impl<Var> ; c'est la même valeur pour "Interface" qui est propagée jusqu'en "haut".
| ok, on peut | demander des Var mais ça force à mettre des choses propres à | l'implémentation dans Var (ce qui est particulièrement | génant dans les cas où j'ai des impl1/impl2 qui ont besoin | de choses différentes).
Aucune classe abstraite ne contient de données membres. Les fonctions membres sont toutes virtuelles -- pour la plupart pure. Si tu envisages deux implémentations différentes pour Var, il n'y a pas de problème tant que les sémantiques de l'interface sont respectées.
| Si c'est Decl_impl<Var> c'est un Var et ça me gène aussi.
Là, je ne te suis pas. Pourquoi cela te gêne ? Pour la plus grande part des analyses, seules les classes interfaces sont nécessaires -- et elles ne supportent aucune opération non-const.
Là où on a besoin des classes d'implémentation, c'est quand on construit un graphe où on veut faire une opération non-const ; mais dans ces cas on opère sur Var_impl et rarement sur Decl_impl<> -- de toute façon, il n'y a pas de moyen d'avoir un Decl_impl<> par la classe de visite.
