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.