Discussion :

[deubelte]

Bonjour,

Dans l'un de ses livres, Scott Meyers nous parle de la signification du mot clé typename (itme 42). Il nous dit que typename permet de préciser au compilateur la présence d'un type dépendant d'un template, afin que le compilateur ne le confonde pas avec une variable locale.

Il donne alors l'exemple suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
template<typename C>
void print2nd(const C& container)               // container;
{                                              // this is not valid C++!
  if (container.size() >= 2) {
  C::const_iterator iter(container.begin()); // get iterator to 1st element
  ++iter;                                    // move iter to 2nd element
  int value = *iter;                         // copy that element to an int
  std::cout << value;                        // print the int
  }
}

Ici, le type dépendant (de C ) est bien sûr const_iterator.

Il semble évident que C::const_iterator soit un type "iterator", et que donc que iter soit un iterator.

Mais cela est évident pour le lecteur, pas pour le compilateur. (en effet, cela pourrait très bien être une variable statique de la classe C).

Le problème est qu'au moment de la compilation, C n'est pas connu, et il n'y a aucun moyen de savoir si oui ou non C possède bien un type "const_iterator".

De ce fait, il est nécessaire de mettre le mot clé typename devant C::const_iterator.




Cependant, je viens d'essayer avec VC2010,et le compilateur accepte parfaitement le code ci-dessus. Il ne renvoie pas d'erreur, qu'il y ait typename ou non.

Alors la question que je me pose est la suivante:
Au moment ou Scott Meyers à écrit ce livre, les compilateurs présentaient encore de ce genre de problèmes, mais maintenant, il est possible que les compilateurs savent parfaitement résoudre ce genre d'ambiguïté.



Merci.

[Emmanuel Deloget]

Bonjour,

Dans l'un de ses livres, Scott Meyers nous parle de la signification du mot clé typename (itme 42). Il nous dit que typename permet de préciser au compilateur la présence d'un type dépendant d'un template, afin que le compilateur ne le confonde pas avec une variable locale.

Il donne alors l'exemple suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
template<typename C>
void print2nd(const C& container)               // container;
{                                              // this is not valid C++!
  if (container.size() >= 2) {
  C::const_iterator iter(container.begin()); // get iterator to 1st element
  ++iter;                                    // move iter to 2nd element
  int value = *iter;                         // copy that element to an int
  std::cout << value;                        // print the int
  }
}

Ici, le type dépendant (de C ) est bien sûr const_iterator.

Il semble évident que C::const_iterator soit un type "iterator", et que donc que iter soit un iterator.

Mais cela est évident pour le lecteur, pas pour le compilateur. (en effet, cela pourrait très bien être une variable statique de la classe C).

Le problème est qu'au moment de la compilation, C n'est pas connu, et il n'y a aucun moyen de savoir si oui ou non C possède bien un type "const_iterator".

De ce fait, il est nécessaire de mettre le mot clé typename devant C::const_iterator.




Cependant, je viens d'essayer avec VC2010,et le compilateur accepte parfaitement le code ci-dessus. Il ne renvoie pas d'erreur, qu'il y ait typename ou non.

Alors la question que je me pose est la suivante:
Au moment ou Scott Meyers à écrit ce livre, les compilateurs présentaient encore de ce genre de problèmes, mais maintenant, il est possible que les compilateurs savent parfaitement résoudre ce genre d'ambiguïté.



Merci.

Non, ça vient uniquement du fait que le compilateur de Microsoft ne suit pas le standard C++ pour tout ce qui concerne la compilation des templates. Normallement, le code template doit être valide hors de toute instanciation - pour vérifier ce point, il est censé être précompilé et validé hors de toute instanciation. Ce point était nécessaire pour implémenter le comportement du mot-clef export dans les compilateurs - mais à ma connaissance, un seul compilateur le fait correctement (Commeau C++).

Visual C++ ne fait pas ça - mais ne compile le code template que si il est instancié. A ce moment, le type C est connu, et le compilateur n'a aucun mal à voir que C::const_iterator existe et que c'est un type.

Au niveau du programmeur, ça ne change pas grand chose - si ce n'est ce point particulier et quelques petits autres trucs qui ne sont pas piqués des vers (mais qui servent principalement (et très rarement) aux fondus de code impossible à lire - comme moi par exemple).

[Jean-Marc.Bourguet]

Au moment ou Scott Meyers à écrit ce livre, les compilateurs présentaient encore de ce genre de problèmes, mais maintenant, il est possible que les compilateurs savent parfaitement résoudre ce genre d'ambiguïté.

La situation est plutôt inverse. Historiquement, les compilateurs n'avaient pas besoin de typename. Mais lors de la normalisation, on l'a rendu nécessaire. Ça fait partie de la recherche des noms en deux phases qui a été introduite pour:
- qu'il soit moins facile d'enfreindre l'ODR avec les templates;
- permettre de détecter des erreurs dans les templates lors de la définition des templates;
- résoudre certaines ambiguités (il me semble me souvenir; je n'ai pas d'exemples)
- permettre export (qui augmente la nécessité des deux premiers points, et il n'est pas impossible que le troisième ne soit qu'avec export)

Outre l'utilisation de typename et template pour qualifier les noms dépendants, la recherche des noms en deux phases a changé la manière dont les noms dans les templates étaient résolus; parfois créant des erreurs, parfois changeant le résultat; par exemple pour accéder à un membre d'une base si la base est dépendante d'un paramètre template, il faut rendre ce nom dépendant (un cas où this-> peut être obligatoire).

Ça ne m'étonnerait pas que VC++ ne l'ait toujours pas implémenté ou qu'elle ne soit pas activée par défaut.