Comment fonctionne `is_base_of` ?

Question

Comment fonctionne le code suivant ?

typedef char (&yes)[1];
typedef char (&no)[2];

template <typename B, typename D>
struct Host
{
  operator B*() const;
  operator D*();
};

template <typename B, typename D>
struct is_base_of
{
  template <typename T> 
  static yes check(D*, T);
  static no check(B*, int);

  static const bool value = sizeof(check(Host<B,D>(), int())) == sizeof(yes);
};

//Test sample
class Base {};
class Derived : private Base {};

//Expression is true.
int test[is_base_of<Base,Derived>::value && !is_base_of<Derived,Base>::value];

1. Notez que B est une base privée. Comment cela fonctionne-t-il ?

2. Notez que operator B*() est constant. Pourquoi est-ce important ?

3. Pourquoi est-ce que template<typename T> static yes check(D*, T); mieux que static yes check(B*, int); ?

Note : C'est une version réduite (les macros sont supprimées) de boost::is_base_of . Et cela fonctionne sur une large gamme de compilateurs.

Answer 1

S'ils sont liés

Supposons pour un moment que B est en fait une base de D . Puis pour l'appel à check les deux versions sont viables car Host peut être converti en D* y B* . Il s'agit d'une séquence de conversion définie par l'utilisateur et décrite par 13.3.3.1.2 de Host<B, D> a D* y B* respectivement. Pour trouver les fonctions de conversion qui peuvent convertir la classe, les fonctions candidates suivantes sont synthétisées pour la première check selon la fonction 13.3.1.5/1

D* (Host<B, D>&)

La première fonction de conversion n'est pas candidate, car B* ne peut pas être converti en D* .

Pour la deuxième fonction, les candidats suivants existent :

B* (Host<B, D> const&)
D* (Host<B, D>&)

Ce sont les deux fonctions de conversion candidates qui prennent l'objet hôte. La première le prend par référence constante, et la seconde ne le prend pas. Ainsi, la seconde correspond mieux à l'objet non-const. *this (l'objet argument implicite de l'objet ) par 13.3.3.2/3b1sb4 et est utilisé pour convertir en B* pour le deuxième check fonction.

Si vous voulez supprimer le const, nous aurions les candidats suivants

B* (Host<B, D>&)
D* (Host<B, D>&)

Cela signifierait que nous ne pouvons plus sélectionner par constance. Dans un scénario ordinaire de résolution de surcharge, l'appel serait maintenant ambigu parce que normalement le type de retour ne participe pas à la résolution de surcharge. Pour les fonctions de conversion, cependant, il existe une porte dérobée. Si deux fonctions de conversion sont aussi bonnes l'une que l'autre, alors leur type de retour décide qui est le meilleur selon 13.3.3/1 . Ainsi, si vous enlevez le const, alors le premier sera pris, car B* se convertit mieux en B* que D* a B* .

Maintenant, quelle séquence de conversion définie par l'utilisateur est la meilleure ? Celle de la deuxième ou de la première fonction de contrôle ? La règle est que les séquences de conversion définies par l'utilisateur ne peuvent être comparées que si elles utilisent la même fonction de conversion ou le même constructeur, conformément à la norme 13.3.3.2/3b2 . C'est exactement le cas ici : Les deux utilisent la deuxième fonction de conversion. Remarquez qu'ainsi le const est important car il oblige le compilateur à prendre la deuxième fonction de conversion.

Puisque nous pouvons les comparer, lequel est le meilleur ? La règle est que la meilleure conversion du type de retour de la fonction de conversion au type de destination l'emporte (encore une fois par 13.3.3.2/3b2 ). Dans ce cas, D* se convertit mieux en D* que de B* . Ainsi la première fonction est sélectionnée et nous reconnaissons l'héritage !

Remarquez que puisque nous n'avons jamais eu besoin de en fait convertir en une classe de base, nous pouvons ainsi reconnaître héritage privé parce que si nous pouvons convertir un D* a un B* ne dépend pas de la forme de l'héritage selon 4.10/3

S'ils ne sont pas liés

Supposons maintenant qu'ils ne sont pas liés par héritage. Ainsi, pour la première fonction, nous avons les candidats suivants

D* (Host<B, D>&) 

Et pour le second, nous avons maintenant une autre série

B* (Host<B, D> const&)

Puisque nous ne pouvons pas convertir D* a B* si nous n'avons pas de relation d'héritage, nous n'avons maintenant aucune fonction de conversion commune parmi les deux séquences de conversion définies par l'utilisateur ! Ainsi, nous serions ambiguë si ce n'est que la première fonction est un modèle. Les modèles sont un second choix lorsqu'il existe une fonction non-modèle qui est tout aussi bonne selon les critères suivants 13.3.3/1 . Ainsi, nous sélectionnons la fonction non modèle (la deuxième) et nous reconnaissons qu'il n'y a pas d'héritage entre B y D !

Answer 2

Voyons comment cela fonctionne en examinant les étapes.

Commencez par le sizeof(check(Host<B,D>(), int())) partie. Le compilateur peut rapidement voir que cette check(...) est une expression d'appel de fonction, elle doit donc effectuer une résolution de surcharge sur check . Deux surcharges de candidats sont disponibles, template <typename T> yes check(D*, T); y no check(B*, int); . Si le premier est choisi, vous obtenez sizeof(yes) sinon sizeof(no)

Ensuite, regardons la résolution de la surcharge. La première surcharge est une instanciation de template check<int> (D*, T=int) et le deuxième candidat est check(B*, int) . Les arguments réels fournis sont Host<B,D> y int() . Le second paramètre ne les distingue clairement pas ; il sert simplement à faire de la première surcharge un modèle. Nous verrons plus tard pourquoi la partie modèle est pertinente.

Regardez maintenant les séquences de conversion qui sont nécessaires. Pour la première surcharge, nous avons Host<B,D>::operator D* - une conversion définie par l'utilisateur. Pour la seconde, la surcharge est plus délicate. Nous avons besoin d'un B*, mais il existe deux séquences de conversion possibles. L'une est via Host<B,D>::operator B*() const . Si (et seulement si) B et D sont liés par héritage, la séquence de conversion sera Host<B,D>::operator D*() + D*->B* existent. Supposons maintenant que D hérite effectivement de B. Les deux séquences de conversion sont les suivantes Host<B,D> -> Host<B,D> const -> operator B* const -> B* y Host<B,D> -> operator D* -> D* -> B* .

Donc, pour les catégories B et D, no check(<Host<B,D>(), int()) serait ambiguë. Par conséquent, le modèle yes check<int>(D*, int) est choisi. Toutefois, si D n'hérite pas de B, alors no check(<Host<B,D>(), int()) n'est pas ambiguë. À ce stade, la résolution des surcharges ne peut pas se faire sur la base de la séquence de conversion la plus courte. Cependant, à séquences de conversion égales, la résolution de surcharge préfère les fonctions non-modèles, c'est-à-dire no check(B*, int) .

Vous voyez maintenant pourquoi le fait que l'héritage soit privé n'a pas d'importance : cette relation ne sert qu'à éliminer no check(Host<B,D>(), int()) de la résolution des surcharges avant que le contrôle d'accès n'ait lieu. Et vous voyez également pourquoi le operator B* const doit être const : sinon, il n'y a pas besoin de l'attribut Host<B,D> -> Host<B,D> const étape, aucune ambiguïté, et no check(B*, int) serait toujours choisi.

Answer 3

Le site private est complètement ignoré par is_base_of car la résolution des surcharges intervient avant les contrôles d'accessibilité.

Vous pouvez le vérifier simplement :

class Foo
{
public:
  void bar(int);
private:
  void bar(double);
};

int main(int argc, char* argv[])
{
  Foo foo;
  double d = 0.3;
  foo.bar(d);       // Compiler error, cannot access private member function
}

Il en va de même ici, le fait que B est une base privée n'empêche pas la vérification d'avoir lieu, elle empêcherait seulement la conversion, mais nous ne demandons jamais la conversion réelle ;)

Answer 4

Cela a peut-être quelque chose à voir avec l'ordre partiel de résolution des surcharges. D* est plus spécialisé que B* dans le cas où D dérive de B.

Les détails exacts sont assez compliqués. Vous devez déterminer les préséances des différentes règles de résolution des surcharges. L'ordre partiel en est une. Les longueurs/types de séquences de conversion en sont une autre. Enfin, si deux fonctions viables sont jugées de qualité égale, les non-modèles sont préférés aux modèles de fonctions.

Je n'ai jamais eu besoin de chercher comment ces règles interagissent. Mais il semble que l'ordre partiel domine les autres règles de résolution des surcharges. Lorsque D ne dérive pas de B, les règles d'ordre partiel ne s'appliquent pas et le non-modèle est plus attrayant. Lorsque D dérive de B, l'ordre partiel entre en jeu et rend le modèle de fonction plus attrayant - comme il semble.

Quant au fait que l'héritage soit prive : le code ne demande jamais une conversion de D* en B* qui nécessiterait un héritage public.

Answer 5

En suivant votre deuxième question, notez que si ce n'était pas pour const, Host serait mal formé si instancié avec B == D. Mais is_base_of est conçu de telle sorte que chaque classe est une base d'elle-même, donc un des opérateurs de conversion doit être const.