Come funziona `is_base_of`?

Come funziona il codice seguente?

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. Nota che Bè una base privata. Come funziona?

2. Nota che operator B*()è const. Perché è importante?

3. Perché è template<typename T> static yes check(D*, T);meglio di static yes check(B*, int);?

Nota : è una versione ridotta (le macro vengono rimosse) di boost::is_base_of. E questo funziona su un'ampia gamma di compilatori.

Se sono correlati

Supponiamo per un momento che Bsia effettivamente una base di D. Quindi per la chiamata a check, entrambe le versioni sono valide perché Hostpossono essere convertite in D* e B* . È una sequenza di conversione definita dall'utente come descritta rispettivamente da 13.3.3.1.2da Host<B, D>a D*e B*. Per trovare funzioni di conversione che possono convertire la classe, le seguenti funzioni candidate vengono sintetizzate per la prima checkfunzione secondo13.3.1.5/1

D* (Host<B, D>&)

La prima funzione di conversione non è una candidata, perché B*non può essere convertita in D*.

Per la seconda funzione esistono i seguenti candidati:

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

Questi sono i due candidati alla funzione di conversione che accettano l'oggetto host. Il primo lo prende per riferimento const, e il secondo no. Quindi il secondo è una corrispondenza migliore per l' *thisoggetto non const (l' argomento dell'oggetto implicito ) da 13.3.3.2/3b1sb4e viene utilizzato per la conversione B*per la seconda checkfunzione.

Se rimuovessi const, avremmo i seguenti candidati

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

Ciò significherebbe che non possiamo più selezionare per costanza. In uno scenario di risoluzione dell'overload ordinario, la chiamata ora sarebbe ambigua perché normalmente il tipo restituito non parteciperà alla risoluzione dell'overload. Per le funzioni di conversione, tuttavia, esiste una backdoor. Se due funzioni di conversione sono ugualmente valide, il tipo restituito decide chi è il migliore in base a 13.3.3/1. Pertanto, se si rimuove la const, verrà presa la prima, perché si B*converte meglio in B*che D*in B*.

Ora quale sequenza di conversione definita dall'utente è migliore? Quello per la seconda o la prima funzione di controllo? La regola è che le sequenze di conversione definite dall'utente possono essere confrontate solo se utilizzano la stessa funzione di conversione o costruttore secondo 13.3.3.2/3b2. Questo è esattamente il caso qui: entrambi usano la seconda funzione di conversione. Si noti che quindi const è importante perché forza il compilatore a prendere la seconda funzione di conversione.

Dal momento che possiamo confrontarli, qual è il migliore? La regola è che la migliore conversione dal tipo di ritorno della funzione di conversione al tipo di destinazione vince (di nuovo da 13.3.3.2/3b2). In questo caso, D*converte meglio in D*che in B*. Così viene selezionata la prima funzione e riconosciamo l'eredità!

Si noti che poiché non abbiamo mai avuto bisogno di convertirci effettivamente in una classe base, possiamo quindi riconoscere l'ereditarietà privata perché se possiamo convertire da a D*a a B*non dipende dalla forma di ereditarietà secondo4.10/3

Se non sono correlati

Supponiamo ora che non siano correlati per eredità. Quindi per la prima funzione abbiamo i seguenti candidati

D* (Host<B, D>&) 

E per il secondo ora abbiamo un altro set

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

Poiché non possiamo convertire D*in B*se non abbiamo una relazione di ereditarietà, ora non abbiamo una funzione di conversione comune tra le due sequenze di conversione definite dall'utente! Pertanto, saremmo ambigui se non fosse per il fatto che la prima funzione è un modello. I modelli sono la seconda scelta quando esiste una funzione non modello che è altrettanto buona secondo 13.3.3/1. Quindi, selezioniamo la funzione non modello (seconda) e riconosciamo che non esiste eredità tra Be D!

Scopriamo come funziona guardando i passaggi.

Inizia con la sizeof(check(Host<B,D>(), int()))parte. Il compilatore può vedere rapidamente che questa check(...)è un'espressione di chiamata di funzione, quindi deve eseguire la risoluzione dell'overload check. Sono disponibili due overload candidati template <typename T> yes check(D*, T);e no check(B*, int);. Se viene scelto il primo, ottieni sizeof(yes), altrimentisizeof(no)

Successivamente, esaminiamo la risoluzione del sovraccarico. Il primo overload è un'istanza del modello check<int> (D*, T=int)e il secondo candidato lo è check(B*, int). Gli argomenti effettivi forniti sono Host<B,D>e int(). Il secondo parametro chiaramente non li distingue; serviva semplicemente a rendere il primo overload un modello. Vedremo più avanti perché la parte del modello è rilevante.

Ora guarda le sequenze di conversione necessarie. Per il primo sovraccarico, abbiamo Host<B,D>::operator D*: una conversione definita dall'utente. Per il secondo, il sovraccarico è più complicato. Abbiamo bisogno di un B *, ma forse ci sono due sequenze di conversione. Uno è via Host<B,D>::operator B*() const. Se (e solo se) B e D sono legati per eredità, la sequenza di conversione Host<B,D>::operator D*()+ D*->B*esisterà. Supponiamo ora che D erediti effettivamente da B. Le due sequenze di conversione sono Host<B,D> -> Host<B,D> const -> operator B* const -> B*e Host<B,D> -> operator D* -> D* -> B*.

Quindi, per i correlati B e D, no check(<Host<B,D>(), int())sarebbe ambiguo. Di conseguenza, yes check<int>(D*, int)viene scelto il modello . Tuttavia, se D non eredita da B, no check(<Host<B,D>(), int())non è ambiguo. A questo punto, la risoluzione del sovraccarico non può avvenire in base alla sequenza di conversione più breve. Tuttavia, a parità di sequenze di conversione, la risoluzione del sovraccarico preferisce funzioni non template, ad es no check(B*, int).

Ora capisci perché non importa che l'eredità sia privata: quella relazione serve solo ad eliminare no check(Host<B,D>(), int())dalla risoluzione del sovraccarico prima che avvenga il controllo dell'accesso. E vedi anche perché il operator B* constdeve essere const: altrimenti non c'è bisogno del Host<B,D> -> Host<B,D> constpasso, nessuna ambiguità, e no check(B*, int)verrebbe sempre scelto.

Il privatebit viene completamente ignorato da is_base_ofperché la risoluzione del sovraccarico avviene prima dei controlli di accessibilità.

Puoi verificarlo semplicemente:

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
}

Lo stesso vale qui, il fatto che Bsia una base privata non impedisce che il controllo abbia luogo, impedirebbe solo la conversione, ma non chiediamo mai la conversione effettiva;)

Forse ha qualcosa a che fare con l'ordinamento parziale rispetto alla risoluzione del sovraccarico. D * è più specializzato di B * nel caso in cui D deriva da B.

I dettagli esatti sono piuttosto complicati. Devi capire le priorità di varie regole di risoluzione del sovraccarico. L'ordinamento parziale è uno. Lunghezze / tipi di sequenze di conversione è un altro. Infine, se due funzioni praticabili sono ritenute ugualmente valide, i modelli non vengono scelti rispetto ai modelli di funzione.

Non ho mai avuto bisogno di cercare come interagiscono queste regole. Ma sembra che l'ordinamento parziale stia dominando le altre regole di risoluzione del sovraccarico. Quando D non deriva da B, le regole di ordinamento parziale non si applicano e il non modello è più attraente. Quando D deriva da B, l'ordinamento parziale entra in gioco e rende il modello di funzione più attraente, come sembra.

Per quanto riguarda l'ereditarietà che è privata: il codice non richiede mai una conversione da D * a B * che richiederebbe un'eredità pubblica.

Seguendo la tua seconda domanda, nota che se non fosse per const, Host sarebbe mal formato se istanziato con B == D.Ma ​​is_base_of è progettato in modo tale che ogni classe sia una base di se stessa, quindi uno degli operatori di conversione deve essere const.