Pourquoi dois-je avoir pour modèle d'accès de la base de membres de la classe par le biais de la ce pointeur?

Réponse courte: afin de rendre x une personne à charge nom, de sorte que la recherche est différée jusqu'à ce que le paramètre de modèle est connu.

Réponse longue: quand un compilateur voit un modèle, il est censé effectuer certains contrôles immédiatement, sans voir le paramètre de modèle. D'autres sont différés jusqu'à ce que le paramètre est connu. Il est appelé à deux phases de compilation et de MSVC ne pas le faire, mais il est requis par la norme et mis en œuvre par les autres grands compilateurs. Si vous le souhaitez, le compilateur doit compiler le modèle dès qu'il la voit (une sorte de interne de l'arbre d'analyse de la représentation), et de reporter la compilation de l'instanciation jusqu'à ce que plus tard.

Les contrôles qui sont effectués sur le modèle lui-même, plutôt que sur les instanciations de, exiger que le compilateur être en mesure de résoudre la grammaire du code dans le modèle.

En C++ (et C), afin de résoudre la grammaire de code, vous avez parfois besoin de savoir si quelque chose est un type ou pas. Par exemple:

#if WANT_POINTER
    typedef int A;
#else
    int A;
#endif
static const int x = 2;
template <typename T> void foo() { A *x = 0; }

si A est un type qui déclare un pointeur (sans autre effet que de faire de l'ombre aux mondiaux x). Si A est un objet, c'est la multiplication (et à l'exception de quelques surcharge d'opérateur c'est illégal, l'affectation à une rvalue). Si c'est faux, cette erreur doit être diagnostiqué dans la phase 1, il est défini par la norme pour être une erreur dans le modèle, non pas dans une particulier de l'instanciation. Même si le modèle n'est jamais instanciée, si A est un int puis le code ci-dessus est mal formé et doivent être diagnostiqués, comme il le serait si foo n'était pas un modèle, mais une simple fonction.

Maintenant, la norme dit que les noms qui ne sont pas dépend des paramètres de modèle doit être résolu dans la phase 1. A ici n'est pas une personne à charge nom, il se réfère à la même chose quel que soit le type T. Il doit donc être défini avant que le modèle est défini pour être trouvé et vérifié dans la phase 1.

T::A serait un nom qui dépend de T. On ne peut pas savoir à l'étape 1 si c'est un type ou pas. Le type qui pourront éventuellement être utilisés comme T dans une instanciation tout à fait probable n'est même pas encore défini, et même si c'était nous ne savons pas quel type(s) seront utilisées comme paramètre du modèle. Mais nous avons à résoudre la grammaire afin de faire de notre précieux phase 1 vérifie mal formé modèles. Si la norme est une règle pour dépendante des noms - le compilateur doit supposer qu'ils sont non-types, à moins qualifiés avec typename de préciser qu'ils sont types, ou utilisé sans ambiguïté dans certains contextes. Par exemple, dans template <typename T> struct Foo : T::A {};, T::A est utilisée comme classe de base et est donc sans ambiguïté un type. Si Foo est instancié par un type qui a un membre de données A au lieu d'une étude de type A, c'est une erreur dans le code fait l'instanciation (phase 2), et non pas une erreur dans le modèle (phase 1).

Mais qu'un modèle de classe avec un dépendant de la classe de base?

template <typename T>
struct Foo : Bar<T> {
    Foo() { A *x = 0; }
};

Est un dépendant de nom ou pas? Avec les classes de base, tout nom pourrait apparaître dans la classe de base. Donc, on pourrait dire que l'Une est une personne à charge nom, et la traiter comme une non-type. Cela aurait l'effet indésirable que chaque nom Foo est dépendant, et donc chaque type utilisé dans Foo (à l'exception des types intégrés) doit être qualifié. À l'intérieur de Toto, vous devriez écrire:

typename std::string s = "hello, world";

parce que std::string serait dépendante de nom, et donc supposé être un non-type, sauf indication contraire. Ouch!

Un deuxième problème en permettant à votre choix de code ( return x; ), c'est que même si Bar est défini avant Foo, et x n'est pas un membre dans cette définition, quelqu'un pourrait définir ultérieurement une spécialisation de Bar pour certains type de Baz, tels que Bar<Baz> a un membre de données x, puis instancier Foo<Baz>. Donc, dans cette instanciation, votre modèle serait de retour le membre de données au lieu de retourner le mondial x. Ou à l'inverse, si le modèle de base définition de Bar avait x, ils pourraient définir une spécialisation sans elle, et votre modèle de chercher un mondial x de retour dans Foo<Baz>. Je pense que cela a été jugé tout aussi surprenante et pénible car le problème que vous avez, mais c'est silencieusement surprenant, par opposition à jeter un surprenant d'erreur.

Pour éviter ces problèmes, la norme en vigueur dit que dépendant de la base de catégories de modèles de classe ne sont pas recherchés pour les noms, sauf si les noms sont déjà dépendants pour une autre raison. Cela s'arrête tout d'être dépendants simplement parce qu'il pourrait être trouvé dans une situation de dépendance de la base. Il a aussi l'effet indésirable que vous voyez - vous devez préciser des trucs à partir de la classe de base ou il ne l'est pas. Il y a trois façons de faire de A dépendante:

• using Bar<T>::A; dans la classe - A maintenant se réfère à quelque chose dans Bar<T>, donc dépendante.
• Bar<T>::A *x = 0; au point d'utilisation - Encore une fois, A est certainement dans Bar<T>. C'est la multiplication depuis typename n'était pas utilisé, peut-être un mauvais exemple, mais nous allons devoir attendre jusqu'à ce que l'instanciation de savoir si operator*(Bar<T>::A, x) renvoie une rvalue. Qui sait, peut-être qu'il fait...
• this->A; au point d'utilisation - A est membre, si ce n'est pas dans Foo, il doit être dans la classe de base, de nouveau, la norme dit que cela le rend dépendant.

Deux-phase de compilation est délicat et difficile, et introduit quelques surprenant exigences supplémentaires pour le verbiage dans votre code. Mais plutôt comme la démocratie, c'est probablement la pire façon possible de faire des choses, à l'exception de tous les autres.

Vous pourriez raisonnablement faire valoir que, dans votre exemple, return x; n'a pas de sens si x est un type imbriqué dans la classe de base, de sorte que la langue doit (a) dire que c'est une personne à charge nom et (2) de la traiter comme un non-type, et votre code devrait fonctionner sans this->. Pour une mesure, vous êtes victime de dommages collatéraux de la solution à un problème qui ne s'applique pas dans votre cas, mais il y a toujours le problème de votre classe de base en introduisant potentiellement sous les noms vous que l'ombre globals, ou ne pas avoir des noms que vous pensiez qu'ils avaient, et un être trouvé à la place.

Vous pourrait aussi argumenter que la valeur par défaut devrait être le contraire de la dépendance des noms (à supposer, sauf en quelque sorte être un objet), ou que la valeur par défaut devrait être plus sensible au contexte (dans std::string s = "";, std::string pourrait être lu comme un type, puisque rien d'autre, grammaire du sens, même si std::string *s = 0; est ambigu). Encore une fois, je ne sais pas tout à fait la façon dont les règles ont été approuvées. Ma conjecture est que le nombre de pages de texte qui serait nécessaire, atténué contre la création d'un lot de règles spécifiques pour lesquels les contextes de prendre un type, un non-type.

OriginalL'auteur

La x est caché au cours de l'héritage. Vous pouvez afficher par:

template <typename T>
class derived : public base<T> {

public:
    using base<T>::x;             //added "using" statement
    int f() { return x; }
};

OriginalL'auteur chrisaycock