accès membres protégés de superclasse en C++ avec des modèles

Question

Pourquoi ne peut pas un compilateur C++ reconnaître que g() et b sont membres hérités de Superclass comme on le voit dans ce code:

template<typename T> struct Superclass { 
protected: 
    int b; 
    void g() {} 
}; 

template<typename T> struct Subclass : public Superclass<T> { 
    void f() { 
    g(); // compiler error: uncategorized 
    b = 3; // compiler error: unrecognized 
    } 
}; 

Si je simplifie Subclass et juste hériter de Subclass<int> puis il compile. Il compile également lorsqu'il qualifie entièrement g() en tant que Superclass<T>::g() et Superclass<T>::b. J'utilise LLVM GCC 4.2.

Remarque: Si je fais g() et b public dans la superclasse, il échoue toujours avec la même erreur.

Answer 1

Cela peut être modifié en tirant les noms dans le champ d'application actuel à l'aide using:

template<typename T> struct Subclass : public Superclass<T> { 
    using Superclass<T>::b; 
    using Superclass<T>::g; 

    void f() { 
    g(); 
    b = 3; 
    } 
}; 

Ou en qualifiant le nom via l'accès pointeur this:

template<typename T> struct Subclass : public Superclass<T> { 
    void f() { 
    this->g(); 
    this->b = 3; 
    } 
}; 

Ou, comme vous avez déjà remarqué, en qualifiant le nom complet.

La raison pour laquelle cela est nécessaire est que C++ ne considère pas les modèles de super-classe pour la résolution de noms (car ils sont alors des noms dépendants et les noms dépendants ne sont pas pris en compte). Cela fonctionne lorsque vous utilisez Superclass<int> parce que ce n'est pas un modèle (c'est instantiation d'un modèle) et donc ses noms imbriqués ne sont pas dépendants noms.

Answer 2

La réponse de Konrad ne demande pas ou ne répond pas au «pourquoi» final de tout cela. Ce n'est pas seulement le comité C++ qui dit arbitrairement «Hé, abandonne les noms dépendants, personne ne les aime de toute façon». Plutôt, le compilateur vérifie les templates avant même qu'ils ne soient instanciés, et il ne peut avoir aucune signification de g() ou de b jusqu'à ce qu'il connaisse T, car il ne peut pas - en général - choisir entre des spécialisations possibles de la classe de base (par exemple SuperClass<X> peut avoir int b tandis que SuperClass<Y> a void b() et SuperClass<Z> n'a pas du tout b). Les formes les plus explicites disent juste "croyez-moi - cela doit provenir de la classe de base au moment de l'instanciation (sinon il y aura alors une erreur de compilation)".