Wie funktioniert `is_base_of`?

Wie funktioniert der folgende code funktioniert?

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. Beachten Sie, dass B privater Basis. Wie funktioniert das?
  2. Beachten Sie, dass operator B*() ist const. Warum ist es wichtig?
  3. Warum ist template<typename T> static yes check(D*, T); besser als static yes check(B*, int); ?

Hinweis: Es ist die reduzierte version (Makros werden entfernt)boost::is_base_of. Und das funktioniert auf Breite Palette von Compilern.

Kommentar zu dem Problem
Es ist sehr verwirrend von Ihnen verwenden den gleichen Bezeichner für eine template-parameter und eine echte Klasse name... Kommentarautor: Matthieu M.
@Matthieu M., ich habe es genommen, auf mich zu korrigieren 🙂 Kommentarautor: Kirill V. Lyadvinsky
Vor einiger Zeit schrieb ich eine alternative Implementierung von is_base_of: ideone.com/T0C1V Es funktioniert nicht mit älteren GCC-Versionen, aber (GCC4.3 gut funktioniert). Kommentarautor: Johannes Schaub - litb
Ok, ich werde einen Spaziergang zu machen. Kommentarautor: jokoon
Diese Implementierung ist nicht korrekt. is_base_of<Base,Base>::value sollte true; dies gibt false. Kommentarautor: chengiz

InformationsquelleAutor der Frage Alexey Malistov | 2010-05-26

  1. 103

    , Wenn Sie verwandt sind

    Lasst uns für einen moment davon ausgehen, dass B ist tatsächlich eine Basis von D. Dann für den Aufruf check beide Varianten sind sinnvoll, weil Host umgewandelt werden können, um D* und B*. Es ist eine benutzerdefinierte Konvertierung-Sequenz, wie beschrieben, durch 13.3.3.1.2 aus Host<B, D> zu D* und B* beziehungsweise. Für die Suche nach Funktionen für die Konvertierung konvertieren kann die Klasse, die folgenden Kandidaten-Funktionen synthetisiert werden, die für die erste check Funktion nach 13.3.1.5/1

    D* (Host<B, D>&)

    Dem ersten Konvertierungs-Funktion ist nicht Kandidat, weil B* können nicht umgewandelt werden, um D*.

    Für die zweite Funktion, die folgenden Kandidaten sind:

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

    Sind die zwei Funktion zur Umsetzung von Kandidaten, die den host-Objekt. Die erste dauert es von const-Referenz, und die zweite nicht. Also das zweite ist eine bessere übereinstimmung für die non-const *this Objekt (die implizite Objekt-argument) von 13.3.3.2/3b1sb4 und wird verwendet, um zu konvertieren B* für die zweite check Funktion.

    Wenn Sie entfernen die const, wir hätten die folgenden Bewerber

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

    Dies würde bedeuten, dass wir nicht auswählen können, indem Sie constness mehr. In eine normale überlast Auflösung Szenario, würde der Aufruf jetzt zweideutig sein, weil normalerweise der Rückgabetyp nicht teilnehmen überlast Auflösung. Für die Konvertierung Funktionen, allerdings gibt es eine Hintertür. Wenn zwei Konvertierungs-Funktionen sind gleich gut, dann ist der Rückgabe-Typ von Ihnen entscheidet, wer am besten nach 13.3.3/1. Wenn Sie also entfernen würde, der const ist, dann wird die erste genommen werden würde, weil B* konvertiert besser zu B* als D* zu B*.

    Nun, was Benutzer definierten conversion-Sequenz ist besser? Die eine für die zweite oder die erste Funktion prüfen? Die Regel ist, dass Benutzer definierten conversion-Sequenzen können nur verglichen werden, wenn Sie verwenden die gleiche Konvertierung Funktion oder eines Konstruktors nach 13.3.3.2/3b2. Das ist genau der Fall hier: Sowohl die zweite Konvertierung Funktion. Beachten Sie, dass damit die const ist wichtig, denn es zwingt den compiler, die zweite zu nehmen-Konvertierung Funktion.

    Da können wir vergleichen - welche ist besser? Die Regel ist, dass der bessere Konvertierung von der Rückgabetyp der Funktion zur Umsetzung der Ziel-Typ gewinnt (wieder durch 13.3.3.2/3b2). In diesem Fall D* konvertiert besser zu D* als B*. Damit ist die erste Funktion ausgewählt ist, und wir erkennen das Erbe!

    Bemerken, dass, da wir nie benötigt, um eigentlich Konvertierung in eine Basis-Klasse, so können wir erkennen, private Vererbung da, ob wir Sie umwandeln können, von einem D* zu einem B* ist nicht abhängig von der form der Vererbung nach 4.10/3

    Wenn Sie nicht mit

    Nun nehmen wir an, Sie sind nicht im Zusammenhang mit Vererbung. Also für die erste Funktion haben wir folgende Kandidaten

    D* (Host<B, D>&)

    Und für die zweite haben wir jetzt einen anderen Satz

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

    Da wir Sie nicht konvertieren D* zu B* wenn wir nicht haben ein Erbe Beziehung, wir haben jetzt keine Allgemeine Konvertierung-Funktion bei der zwei Benutzer-definierten conversion-Sequenzen! Also, wir würden uns mehrdeutig, wenn nicht für die Tatsache, dass die erste Funktion ist eine Vorlage. Vorlagen sind zweite Wahl, wenn es eine nicht-template-Funktion, die genauso gut nach 13.3.3/1. So wählen wir die nicht-template-Funktion (zweite) und wir erkennen, dass es keine Vererbung zwischen B und D!

    InformationsquelleAutor der Antwort Johannes Schaub - litb

  2. 23

    Lassen Sie uns herausfinden, wie es funktioniert, indem man die Schritte.

    Beginnen Sie mit der sizeof(check(Host<B,D>(), int())) Teil. Der compiler schnell erkennen können, dass diese check(...) ist ein Funktionsaufruf, Ausdruck, so muss es zu tun überlast Auflösung auf check. Es gibt zwei Kandidaten überladungen zur Verfügung, template <typename T> yes check(D*, T); und no check(B*, int);. Wenn das erste ausgewählt wird, erhalten Sie sizeof(yes), sonst sizeof(no)

    Als Nächstes schauen wir uns die überlast Auflösung. Die erste überladung ist eine template-Instantiierung check<int> (D*, T=int) und der zweite Kandidat ist check(B*, int). Die eigentlichen Argumente sind Host<B,D> und int(). Der zweite parameter offensichtlich nicht unterscheiden; nur diente, um die ersten überlast-Vorlage. Wir werden später sehen, warum die Vorlage Teil ist relevant.

    Nun einen Blick auf die conversion-Sequenzen, die benötigt werden. Für die erste überlast, wir haben Host<B,D>::operator D* - eine benutzerdefinierte Konvertierung. Für die zweite, die überlastung ist schwieriger. Wir brauchen eine B*, aber es gibt möglicherweise zwei conversion-Sequenzen. Man ist per Host<B,D>::operator B*() const. Wenn (und nur wenn) B und D sind im Zusammenhang mit Vererbung wird die Umwandlung Sequenz Host<B,D>::operator D*() + D*->B* vorhanden. Nehmen Sie jetzt D in der Tat erbt von B. Die beiden conversion-Sequenzen sind Host<B,D> -> Host<B,D> const -> operator B* const -> B* und Host<B,D> -> operator D* -> D* -> B*.

    So, für Verwandte B und D, no check(<Host<B,D>(), int()) würde mehrdeutig. Als Ergebnis, die Vorlagen yes check<int>(D*, int) gewählt wird. Jedoch, wenn D nicht Erben von B, dann no check(<Host<B,D>(), int()) ist nicht mehrdeutig. An diesem Punkt, überlast-Auflösung kann nicht passieren, baed auf kürzeste Umwandlung der Sequenz. Jedoch, bei gleicher conversion-Sequenzen, überlast Auflösung bevorzugt nicht-template-Funktionen, D. H. no check(B*, int).

    Sehen Sie jetzt, warum es egal ist, dass die Vererbung ist privat: das Verhältnis dient nur zu beseitigen no check(Host<B,D>(), int()) von overload resolution vor access check passiert. Und Sie sehen auch, warum die operator B* const muss const: sonst gibt es keine Notwendigkeit für die Host<B,D> -> Host<B,D> const Schritt, keine Zweideutigkeit, und no check(B*, int) würde immer gewählt werden.

    InformationsquelleAutor der Antwort MSalters

  3. 4

    Den private bit wird komplett ignoriert is_base_of wegen überlast Auflösung tritt auf, bevor der Barrierefreiheit überprüft.

    Überprüfen können Sie dies einfach:

    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
}

    Hier gilt das gleiche, die Tatsache, dass B ist eine private Basis nicht verhindern, dass die Prüfung stattfindet, es würde nur verhindern, dass die Umwandlung, aber wir Fragen Sie nie für die eigentliche Konvertierung 😉

    InformationsquelleAutor der Antwort Matthieu M.

  4. 2

    Es hat möglicherweise etwas zu tun mit partiellem Bestell-w.r.t. überlast Auflösung. D* ist mehr als spezialisierte B* im Fall D leitet sich von B.

    Die genauen details sind ziemlich kompliziert. Sie haben, um herauszufinden, die prš verschiedener überlast Auflösung Regeln. Teilweise ist die Reihenfolge. Längen/Arten der Umwandlung von Sequenzen ist eine andere. Schließlich, wenn zwei brauchbare Funktionen werden als gleich gute, nicht-Vorlagen gewählt werden, die über die Funktion Vorlagen.

    Habe ich noch nie benötigt, zu schauen, wie diese Regeln miteinander interagieren. Aber es scheint teilweise ist die Reihenfolge Dominieren die anderen überlast Auflösung Regeln. Wenn D nicht ableiten, von B die partial-ordering-Regeln nicht gelten und die nicht-Vorlage ist attraktiver. Wenn D leitet sich von B, teilweise Bestellung in tritt und macht die Funktion Vorlage mehr attraktiv-wie es scheint.

    Als für die Vererbung wird privete: der code fragt niemals für eine Umstellung von der D* B* die öffentlichkeit erfordern würde inheritence.

    InformationsquelleAutor der Antwort sellibitze

  5. 0

    Folgenden auf Ihre zweite Frage, beachten Sie, dass wenn es nicht für const Host wäre schlecht gebildet, wenn instanziiert mit B == D. Aber is_base_of ist so ausgelegt, dass jede Klasse ist eine Basis von selbst, daher ist eine Konvertierung müssen die Betreiber const.

    InformationsquelleAutor der Antwort Hertz

Schreibe einen Kommentar