Je reprends un code (joie, bonheur) dont une partie aurait
du utiliser des sous-classes et ne le fait pas.
// Declaration anticipée
template <class T> class StateSpace;
// Une qui aurait du être une sous-classe
template <class T> class StateSpaceArc {
StateSpace<T> *root;
};
// La classe elle même
template <class T> class StateSpace {
std::vector< StateSpaceArc<T> > arcs;
};
Je voulais transformer le tout en un truc plus propre,
avec une sous classe
template <class T>
class StateSpace {
class Arc { ... };
];
Mais comment faire sans trop casser le code utilisateur.
Sans template, je sais faire
typedef StateSpace::Arc StateSpaceArc;
mais avec template, j'arrive pas à deviner de syntaxe acceptée par
mon g++.
Toute idée bienvenue, même GNUisme, même pour me dire que
je m'y prends mal, etc.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bruno Personnel
Marc Boyer wrote:
Je reprends un code (joie, bonheur) dont une partie aurait du utiliser des sous-classes et ne le fait pas.
// Declaration anticipée template <class T> class StateSpace; // Une qui aurait du être une sous-classe template <class T> class StateSpaceArc { StateSpace<T> *root; }; // La classe elle même template <class T> class StateSpace { std::vector< StateSpaceArc<T> > arcs; };
Je voulais transformer le tout en un truc plus propre, avec une sous classe template <class T> class StateSpace { class Arc { ... }; ];
Mais comment faire sans trop casser le code utilisateur.
Sans template, je sais faire typedef StateSpace::Arc StateSpaceArc; mais avec template, j'arrive pas à deviner de syntaxe acceptée par mon g++.
Toute idée bienvenue, même GNUisme, même pour me dire que je m'y prends mal, etc.
Marc Boyer
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et ne sera pas considéré même dans les normes à venir. Il existe un débat au sein du comité de normalisation.
Bruno
Marc Boyer wrote:
Je reprends un code (joie, bonheur) dont une partie aurait
du utiliser des sous-classes et ne le fait pas.
// Declaration anticipée
template <class T> class StateSpace;
// Une qui aurait du être une sous-classe
template <class T> class StateSpaceArc {
StateSpace<T> *root;
};
// La classe elle même
template <class T> class StateSpace {
std::vector< StateSpaceArc<T> > arcs;
};
Je voulais transformer le tout en un truc plus propre,
avec une sous classe
template <class T>
class StateSpace {
class Arc { ... };
];
Mais comment faire sans trop casser le code utilisateur.
Sans template, je sais faire
typedef StateSpace::Arc StateSpaceArc;
mais avec template, j'arrive pas à deviner de syntaxe acceptée par
mon g++.
Toute idée bienvenue, même GNUisme, même pour me dire que
je m'y prends mal, etc.
Marc Boyer
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y
a pas de typedef templaté. Donc pas de solution à ce problème. Et ne
sera pas considéré même dans les normes à venir. Il existe un débat au
sein du comité de normalisation.
Je reprends un code (joie, bonheur) dont une partie aurait du utiliser des sous-classes et ne le fait pas.
// Declaration anticipée template <class T> class StateSpace; // Une qui aurait du être une sous-classe template <class T> class StateSpaceArc { StateSpace<T> *root; }; // La classe elle même template <class T> class StateSpace { std::vector< StateSpaceArc<T> > arcs; };
Je voulais transformer le tout en un truc plus propre, avec une sous classe template <class T> class StateSpace { class Arc { ... }; ];
Mais comment faire sans trop casser le code utilisateur.
Sans template, je sais faire typedef StateSpace::Arc StateSpaceArc; mais avec template, j'arrive pas à deviner de syntaxe acceptée par mon g++.
Toute idée bienvenue, même GNUisme, même pour me dire que je m'y prends mal, etc.
Marc Boyer
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et ne sera pas considéré même dans les normes à venir. Il existe un débat au sein du comité de normalisation.
Bruno
Loïc Joly
Bruno Personnel wrote:
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et ne sera pas considéré même dans les normes à venir.
D'où tiens tu cette certitude ?
Il existe un débat au sein du comité de normalisation.
L'existence de ce débat me semble dire que justement, ça existera probablement dans la future version de la norme, bien qu'on ne sache pas encore sous quelle forme.
-- Loïc
Bruno Personnel wrote:
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y
a pas de typedef templaté. Donc pas de solution à ce problème. Et ne
sera pas considéré même dans les normes à venir.
D'où tiens tu cette certitude ?
Il existe un débat au
sein du comité de normalisation.
L'existence de ce débat me semble dire que justement, ça existera
probablement dans la future version de la norme, bien qu'on ne sache pas
encore sous quelle forme.
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et ne sera pas considéré même dans les normes à venir.
D'où tiens tu cette certitude ?
Il existe un débat au sein du comité de normalisation.
L'existence de ce débat me semble dire que justement, ça existera probablement dans la future version de la norme, bien qu'on ne sache pas encore sous quelle forme.
-- Loïc
Bruno Personnel
Loïc Joly wrote:
Bruno Personnel wrote:
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et ne sera pas considéré même dans les normes à venir.
D'où tiens tu cette certitude ?
Il existe un débat au sein du comité de normalisation.
L'existence de ce débat me semble dire que justement, ça existera probablement dans la future version de la norme, bien qu'on ne sache pas encore sous quelle forme.
Non, n'a pas été retenu dans les travaux du WG21. Il en a été débattu, c'est tout. L'idée, c'est que la fonctionnalité n'apporte pas grand chose par elle même et pose un problème sur ce qu'introduit réellment un typedef ? Un type autonome (ou sens class ou function, donc ayant une existence sémantique) ou un alias de type (n'ayant qu'une existence syntaxique) ? Hors les templates portent uniquement (pour l'instant) sur des éléments ayant un existence sémantique.
Bruno
Loïc Joly wrote:
Bruno Personnel wrote:
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il
n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et
ne sera pas considéré même dans les normes à venir.
D'où tiens tu cette certitude ?
Il existe un débat au sein du comité de normalisation.
L'existence de ce débat me semble dire que justement, ça existera
probablement dans la future version de la norme, bien qu'on ne sache pas
encore sous quelle forme.
Non, n'a pas été retenu dans les travaux du WG21. Il en a été débattu,
c'est tout. L'idée, c'est que la fonctionnalité n'apporte pas grand
chose par elle même et pose un problème sur ce qu'introduit réellment
un typedef ? Un type autonome (ou sens class ou function, donc ayant
une existence sémantique) ou un alias de type (n'ayant qu'une existence
syntaxique) ? Hors les templates portent uniquement (pour l'instant)
sur des éléments ayant un existence sémantique.
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et ne sera pas considéré même dans les normes à venir.
D'où tiens tu cette certitude ?
Il existe un débat au sein du comité de normalisation.
L'existence de ce débat me semble dire que justement, ça existera probablement dans la future version de la norme, bien qu'on ne sache pas encore sous quelle forme.
Non, n'a pas été retenu dans les travaux du WG21. Il en a été débattu, c'est tout. L'idée, c'est que la fonctionnalité n'apporte pas grand chose par elle même et pose un problème sur ce qu'introduit réellment un typedef ? Un type autonome (ou sens class ou function, donc ayant une existence sémantique) ou un alias de type (n'ayant qu'une existence syntaxique) ? Hors les templates portent uniquement (pour l'instant) sur des éléments ayant un existence sémantique.
Bruno
Gabriel Dos Reis
Bruno Personnel writes:
| Loïc Joly wrote: | > Bruno Personnel wrote: | > | >> | >> Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il | >> n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et | >> ne sera pas considéré même dans les normes à venir. | > | > | > D'où tiens tu cette certitude ? | > | >> Il existe un débat au sein du comité de normalisation. | > | > | > L'existence de ce débat me semble dire que justement, ça existera | > probablement dans la future version de la norme, bien qu'on ne sache pas | > encore sous quelle forme. | > | | Non, n'a pas été retenu dans les travaux du WG21.
Et qu'est-ce que tu en sais ?
| Il en a été débattu, c'est tout.
Et qu'est-ce que tu en sais ?
| L'idée, c'est que la fonctionnalité n'apporte pas grand | chose par elle même et pose un problème sur ce qu'introduit réellment | un typedef ?
et tu sors ça d'où ?
| Un type autonome (ou sens class ou function, donc ayant | une existence sémantique) ou un alias de type (n'ayant qu'une existence | syntaxique) ? Hors les templates portent uniquement (pour l'instant) | sur des éléments ayant un existence sémantique.
-- Gaby
Bruno Personnel <bruno.personnel@free.fr> writes:
| Loïc Joly wrote:
| > Bruno Personnel wrote:
| >
| >>
| >> Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il
| >> n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et
| >> ne sera pas considéré même dans les normes à venir.
| >
| >
| > D'où tiens tu cette certitude ?
| >
| >> Il existe un débat au sein du comité de normalisation.
| >
| >
| > L'existence de ce débat me semble dire que justement, ça existera
| > probablement dans la future version de la norme, bien qu'on ne sache pas
| > encore sous quelle forme.
| >
|
| Non, n'a pas été retenu dans les travaux du WG21.
Et qu'est-ce que tu en sais ?
| Il en a été débattu, c'est tout.
Et qu'est-ce que tu en sais ?
| L'idée, c'est que la fonctionnalité n'apporte pas grand
| chose par elle même et pose un problème sur ce qu'introduit réellment
| un typedef ?
et tu sors ça d'où ?
| Un type autonome (ou sens class ou function, donc ayant
| une existence sémantique) ou un alias de type (n'ayant qu'une existence
| syntaxique) ? Hors les templates portent uniquement (pour l'instant)
| sur des éléments ayant un existence sémantique.
| Loïc Joly wrote: | > Bruno Personnel wrote: | > | >> | >> Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il | >> n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et | >> ne sera pas considéré même dans les normes à venir. | > | > | > D'où tiens tu cette certitude ? | > | >> Il existe un débat au sein du comité de normalisation. | > | > | > L'existence de ce débat me semble dire que justement, ça existera | > probablement dans la future version de la norme, bien qu'on ne sache pas | > encore sous quelle forme. | > | | Non, n'a pas été retenu dans les travaux du WG21.
Et qu'est-ce que tu en sais ?
| Il en a été débattu, c'est tout.
Et qu'est-ce que tu en sais ?
| L'idée, c'est que la fonctionnalité n'apporte pas grand | chose par elle même et pose un problème sur ce qu'introduit réellment | un typedef ?
et tu sors ça d'où ?
| Un type autonome (ou sens class ou function, donc ayant | une existence sémantique) ou un alias de type (n'ayant qu'une existence | syntaxique) ? Hors les templates portent uniquement (pour l'instant) | sur des éléments ayant un existence sémantique.
-- Gaby
Marc Boyer
Bruno Personnel wrote:
Marc Boyer wrote:
Je reprends un code (joie, bonheur) dont une partie aurait du utiliser des sous-classes et ne le fait pas. [SNIP, le contexte]
Mais comment faire sans trop casser le code utilisateur.
Sans template, je sais faire typedef StateSpace::Arc StateSpaceArc; mais avec template, j'arrive pas à deviner de syntaxe acceptée par mon g++.
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y
a pas de typedef templaté. Donc pas de solution à ce problème.
Donc, même en cas de revirrement du comité, pour du code qui est sensé compiler demain, mieux vaut faire sans. Faut que j'évalue donc l'effort entre écrire un wrapper pour la compatibilité, et laisser les choses en l'état. Question: est-ce que je peux pas faire un wrapper assez simple avec de l'héritage ?
class StateSpaceArc<T>: public StateSpace<T>::Arc {};
Merci,
Marc -- Lying for having sex or lying for making war? Trust US presidents :-(
Bruno Personnel wrote:
Marc Boyer wrote:
Je reprends un code (joie, bonheur) dont une partie aurait
du utiliser des sous-classes et ne le fait pas.
[SNIP, le contexte]
Mais comment faire sans trop casser le code utilisateur.
Sans template, je sais faire
typedef StateSpace::Arc StateSpaceArc;
mais avec template, j'arrive pas à deviner de syntaxe acceptée par
mon g++.
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y
a pas de typedef templaté. Donc pas de solution à ce problème.
Donc, même en cas de revirrement du comité, pour du code qui est
sensé compiler demain, mieux vaut faire sans.
Faut que j'évalue donc l'effort entre écrire un wrapper pour la
compatibilité, et laisser les choses en l'état.
Question: est-ce que je peux pas faire un wrapper assez simple
avec de l'héritage ?
class StateSpaceArc<T>: public StateSpace<T>::Arc {};
Merci,
Marc
--
Lying for having sex or lying for making war? Trust US presidents :-(
Je reprends un code (joie, bonheur) dont une partie aurait du utiliser des sous-classes et ne le fait pas. [SNIP, le contexte]
Mais comment faire sans trop casser le code utilisateur.
Sans template, je sais faire typedef StateSpace::Arc StateSpaceArc; mais avec template, j'arrive pas à deviner de syntaxe acceptée par mon g++.
Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il n'y
a pas de typedef templaté. Donc pas de solution à ce problème.
Donc, même en cas de revirrement du comité, pour du code qui est sensé compiler demain, mieux vaut faire sans. Faut que j'évalue donc l'effort entre écrire un wrapper pour la compatibilité, et laisser les choses en l'état. Question: est-ce que je peux pas faire un wrapper assez simple avec de l'héritage ?
class StateSpaceArc<T>: public StateSpace<T>::Arc {};
Merci,
Marc -- Lying for having sex or lying for making war? Trust US presidents :-(
Bruno (Personnel)
Gabriel Dos Reis wrote:
Bruno Personnel writes:
| Loïc Joly wrote: | > Bruno Personnel wrote: | > | >> | >> Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il | >> n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et | >> ne sera pas considéré même dans les normes à venir. | > | > | > D'où tiens tu cette certitude ? | > | >> Il existe un débat au sein du comité de normalisation. | > | > | > L'existence de ce débat me semble dire que justement, ça existera | > probablement dans la future version de la norme, bien qu'on ne sache pas | > encore sous quelle forme. | > | | Non, n'a pas été retenu dans les travaux du WG21.
Et qu'est-ce que tu en sais ?
| Il en a été débattu, c'est tout.
Et qu'est-ce que tu en sais ?
| L'idée, c'est que la fonctionnalité n'apporte pas grand | chose par elle même et pose un problème sur ce qu'introduit réellment | un typedef ?
et tu sors ça d'où ?
| Un type autonome (ou sens class ou function, donc ayant | une existence sémantique) ou un alias de type (n'ayant qu'une existence | syntaxique) ? Hors les templates portent uniquement (pour l'instant) | sur des éléments ayant un existence sémantique.
-- Gaby
Origine: papotage de certains membres du WG21. Sinon, pour ce qui est retenu comme points à prendre en considération, vois les travaux du WG21 au diku. Les comptes rendus sont publics.
Bruno
Gabriel Dos Reis wrote:
Bruno Personnel <bruno.personnel@free.fr> writes:
| Loïc Joly wrote:
| > Bruno Personnel wrote:
| >
| >>
| >> Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il
| >> n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et
| >> ne sera pas considéré même dans les normes à venir.
| >
| >
| > D'où tiens tu cette certitude ?
| >
| >> Il existe un débat au sein du comité de normalisation.
| >
| >
| > L'existence de ce débat me semble dire que justement, ça existera
| > probablement dans la future version de la norme, bien qu'on ne sache pas
| > encore sous quelle forme.
| >
|
| Non, n'a pas été retenu dans les travaux du WG21.
Et qu'est-ce que tu en sais ?
| Il en a été débattu, c'est tout.
Et qu'est-ce que tu en sais ?
| L'idée, c'est que la fonctionnalité n'apporte pas grand
| chose par elle même et pose un problème sur ce qu'introduit réellment
| un typedef ?
et tu sors ça d'où ?
| Un type autonome (ou sens class ou function, donc ayant
| une existence sémantique) ou un alias de type (n'ayant qu'une existence
| syntaxique) ? Hors les templates portent uniquement (pour l'instant)
| sur des éléments ayant un existence sémantique.
-- Gaby
Origine: papotage de certains membres du WG21.
Sinon, pour ce qui est retenu comme points à prendre en considération,
vois les travaux du WG21 au diku. Les comptes rendus sont publics.
| Loïc Joly wrote: | > Bruno Personnel wrote: | > | >> | >> Impossible si tu veux continuer à accéder à des StateSpaceArc<T>, il | >> n'y a pas de typedef templaté. Donc pas de solution à ce problème. Et | >> ne sera pas considéré même dans les normes à venir. | > | > | > D'où tiens tu cette certitude ? | > | >> Il existe un débat au sein du comité de normalisation. | > | > | > L'existence de ce débat me semble dire que justement, ça existera | > probablement dans la future version de la norme, bien qu'on ne sache pas | > encore sous quelle forme. | > | | Non, n'a pas été retenu dans les travaux du WG21.
Et qu'est-ce que tu en sais ?
| Il en a été débattu, c'est tout.
Et qu'est-ce que tu en sais ?
| L'idée, c'est que la fonctionnalité n'apporte pas grand | chose par elle même et pose un problème sur ce qu'introduit réellment | un typedef ?
et tu sors ça d'où ?
| Un type autonome (ou sens class ou function, donc ayant | une existence sémantique) ou un alias de type (n'ayant qu'une existence | syntaxique) ? Hors les templates portent uniquement (pour l'instant) | sur des éléments ayant un existence sémantique.
-- Gaby
Origine: papotage de certains membres du WG21. Sinon, pour ce qui est retenu comme points à prendre en considération, vois les travaux du WG21 au diku. Les comptes rendus sont publics.
Bruno
Jean-Marc Bourguet
"Bruno (Personnel)" writes:
Origine: papotage de certains membres du WG21. Sinon, pour ce qui est retenu comme points à prendre en considération, vois les travaux du WG21 au diku. Les comptes rendus sont publics.
Puisque tu connais si bien les membres du comite, peux-tu me rappeler les auteurs de la proposition "Template aliases for C++"?
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
Origine: papotage de certains membres du WG21. Sinon, pour ce qui
est retenu comme points à prendre en considération, vois les travaux
du WG21 au diku. Les comptes rendus sont publics.
Puisque tu connais si bien les membres du comite, peux-tu me rappeler
les auteurs de la proposition "Template aliases for C++"?
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
Origine: papotage de certains membres du WG21. Sinon, pour ce qui est retenu comme points à prendre en considération, vois les travaux du WG21 au diku. Les comptes rendus sont publics.
Puisque tu connais si bien les membres du comite, peux-tu me rappeler les auteurs de la proposition "Template aliases for C++"?
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
"Bruno (Personnel)" writes:
[...]
| > | Non, n'a pas été retenu dans les travaux du WG21. | > | > Et qu'est-ce que tu en sais ?
[...]
| Origine: papotage de certains membres du WG21.
Quels « certains » membres du WG21 ?
| Sinon, pour ce qui est retenu comme points à prendre en considération, | vois les travaux du WG21 au diku. Les comptes rendus sont publics.
lesquels exactement ?
Petite précision : j'étais à Santa Cruz lorsque l'EWG (Evolution Working Group) a commencé ses travaux. S'il y a un sujet qui a réuni et le CWG et l'EWG toute une après-midi, c'est bien le sujet de typedef template, où plusieurs alternatives ont été discutées ; à la suite de quoi une approche a été favorisée. Après discussion avec certains members du LWG (W. Brown notamment) qui m'ont montré des utilisations qu'ils en feraient dans leurs propres codes (le cas de W. Brown m'a paru le plus convaincant), j'ai travaillé sur quelque chose qui devrait contenir les deux principales sémantiques. Cela a donné lieu à la note « Proposal to add template aliases to C++ » écrite conjointement avec M. Marcus,
qui a fait l'objet de discussions dans le EWG à la réunion d'Oxford. S'en est suivi un exposé, en séance pléniaire du tout le comité (pas seulement du EWG), de W. Brown sur ses besoins de typedef template (un exposé fort intéressant). Voir la note « A case for template aliasing »
| > | Non, n'a pas été retenu dans les travaux du WG21.
| >
| > Et qu'est-ce que tu en sais ?
[...]
| Origine: papotage de certains membres du WG21.
Quels « certains » membres du WG21 ?
| Sinon, pour ce qui est retenu comme points à prendre en considération,
| vois les travaux du WG21 au diku. Les comptes rendus sont publics.
lesquels exactement ?
Petite précision : j'étais à Santa Cruz lorsque l'EWG (Evolution
Working Group) a commencé ses travaux. S'il y a un sujet qui a réuni
et le CWG et l'EWG toute une après-midi, c'est bien le sujet de
typedef template, où plusieurs alternatives ont été discutées ; à la
suite de quoi une approche a été favorisée.
Après discussion avec certains members du LWG (W. Brown notamment) qui
m'ont montré des utilisations qu'ils en feraient dans leurs propres
codes (le cas de W. Brown m'a paru le plus convaincant), j'ai
travaillé sur quelque chose qui devrait contenir les deux principales
sémantiques. Cela a donné lieu à la note « Proposal to add template
aliases to C++ » écrite conjointement avec M. Marcus,
qui a fait l'objet de discussions dans le EWG à la réunion d'Oxford.
S'en est suivi un exposé, en séance pléniaire du tout le comité (pas
seulement du EWG), de W. Brown sur ses besoins de typedef template (un
exposé fort intéressant). Voir la note « A case for template aliasing »
| > | Non, n'a pas été retenu dans les travaux du WG21. | > | > Et qu'est-ce que tu en sais ?
[...]
| Origine: papotage de certains membres du WG21.
Quels « certains » membres du WG21 ?
| Sinon, pour ce qui est retenu comme points à prendre en considération, | vois les travaux du WG21 au diku. Les comptes rendus sont publics.
lesquels exactement ?
Petite précision : j'étais à Santa Cruz lorsque l'EWG (Evolution Working Group) a commencé ses travaux. S'il y a un sujet qui a réuni et le CWG et l'EWG toute une après-midi, c'est bien le sujet de typedef template, où plusieurs alternatives ont été discutées ; à la suite de quoi une approche a été favorisée. Après discussion avec certains members du LWG (W. Brown notamment) qui m'ont montré des utilisations qu'ils en feraient dans leurs propres codes (le cas de W. Brown m'a paru le plus convaincant), j'ai travaillé sur quelque chose qui devrait contenir les deux principales sémantiques. Cela a donné lieu à la note « Proposal to add template aliases to C++ » écrite conjointement avec M. Marcus,
qui a fait l'objet de discussions dans le EWG à la réunion d'Oxford. S'en est suivi un exposé, en séance pléniaire du tout le comité (pas seulement du EWG), de W. Brown sur ses besoins de typedef template (un exposé fort intéressant). Voir la note « A case for template aliasing »
