Como funciona `is_base_of`?

Como funciona o código a seguir?

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. Observe que Bé uma base privada. Como é que isso funciona?

2. Observe que operator B*()é const. Por que isso é importante?

3. Porque é template<typename T> static yes check(D*, T); melhor do que static yes check(B*, int);?

Nota : É uma versão reduzida (macros são removidas) de boost::is_base_of. E isso funciona em uma ampla gama de compiladores.

Se eles são relacionados

Por um momento, vamos supor que Bseja realmente uma base de D. Então, para a chamada para check, ambas as versões são viáveis ​​porque Hostpodem ser convertidas para D* e B* . É uma sequência de conversão definida pelo usuário, conforme descrito por 13.3.3.1.2de Host<B, D>para D*e B*respectivamente. Para encontrar funções de conversão que podem converter a classe, as seguintes funções candidatas são sintetizadas para a primeira checkfunção de acordo com13.3.1.5/1

D* (Host<B, D>&)

A primeira função de conversão não é candidata, porque B*não pode ser convertida para D*.

Para a segunda função, existem os seguintes candidatos:

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

Esses são os dois candidatos à função de conversão que usam o objeto host. O primeiro o considera por referência const e o segundo não. Assim, o segundo é uma combinação melhor para o *thisobjeto não const (o argumento do objeto implícito ) por13.3.3.2/3b1sb4 e é usado para converter para B*para a segunda checkfunção.

Se você remover o const, teríamos os seguintes candidatos

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

Isso significaria que não podemos mais selecionar por constância. Em um cenário de resolução de sobrecarga comum, a chamada agora seria ambígua porque normalmente o tipo de retorno não participará da resolução de sobrecarga. Para funções de conversão, no entanto, existe uma porta dos fundos. Se duas funções de conversão forem igualmente boas, o tipo de retorno delas decidirá quem é a melhor de acordo com 13.3.3/1. Portanto, se você remover o const, o primeiro será usado, porque B*converte melhor em do B*que D*em B*.

Agora, qual sequência de conversão definida pelo usuário é melhor? Aquele para a segunda ou a primeira função de verificação? A regra é que as sequências de conversão definidas pelo usuário só podem ser comparadas se usarem a mesma função de conversão ou construtor de acordo com 13.3.3.2/3b2. Este é exatamente o caso aqui: Ambos usam a segunda função de conversão. Observe que, portanto, const é importante porque força o compilador a assumir a segunda função de conversão.

Já que podemos compará-los - qual é o melhor? A regra é que a melhor conversão do tipo de retorno da função de conversão para o tipo de destino vence (novamente por 13.3.3.2/3b2). Nesse caso, D*converte melhor em do D*que em B*. Assim, a primeira função é selecionada e reconhecemos a herança!

Observe que, uma vez que nunca precisamos realmente converter para uma classe base, podemos reconhecer a herança privada porque se podemos converter de umD* para a B*não depende da forma de herança de acordo com4.10/3

Se eles não são relacionados

Agora vamos assumir que eles não estão relacionados por herança. Assim, para a primeira função, temos os seguintes candidatos

D* (Host<B, D>&) 

E para o segundo, agora temos outro conjunto

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

Visto que não podemos converter D*para B*se não tivermos uma relação de herança, agora não temos nenhuma função de conversão comum entre as duas sequências de conversão definidas pelo usuário! Assim, seríamos ambíguos se não fosse o fato de que a primeira função é um modelo. Os modelos são a segunda escolha quando há uma função não-modelo que é igualmente boa de acordo com 13.3.3/1. Assim, selecionamos a função não modelo (a segunda) e reconhecemos que não há herança entre Be D!

Vamos descobrir como isso funciona observando as etapas.

Comece com a sizeof(check(Host<B,D>(), int()))parte. O compilador pode ver rapidamente que esta check(...)é uma expressão de chamada de função, portanto, ele precisa fazer a resolução de sobrecarga check. Existem duas sobrecargas candidatas disponíveis, template <typename T> yes check(D*, T);eno check(B*, int); . Se o primeiro for escolhido, você obtémsizeof(yes) , senãosizeof(no)

A seguir, vamos examinar a resolução de sobrecarga. A primeira sobrecarga é uma instanciação de modelo check<int> (D*, T=int)e a segunda candidata é check(B*, int). Os argumentos reais fornecidos são Host<B,D>e int(). O segundo parâmetro claramente não os distingue; apenas serviu para tornar a primeira sobrecarga um modelo. Veremos mais tarde porque a parte do modelo é relevante.

Agora veja as sequências de conversão necessárias. Para a primeira sobrecarga, temos Host<B,D>::operator D*- uma conversão definida pelo usuário. Para o segundo, a sobrecarga é mais complicada. Precisamos de um B *, mas possivelmente existem duas sequências de conversão. Um é via Host<B,D>::operator B*() const. Se (e somente se) B e D estão relacionados por herança será a sequência de conversão Host<B,D>::operator D*()+ D*->B*existir. Agora suponha que D realmente herda de B. As duas sequências de conversão são Host<B,D> -> Host<B,D> const -> operator B* const -> B*e Host<B,D> -> operator D* -> D* -> B*.

Portanto, para B e D relacionados, no check(<Host<B,D>(), int())seria ambíguo. Como resultado, o modelo yes check<int>(D*, int)é escolhido. No entanto, se D não herda de B, então no check(<Host<B,D>(), int())não é ambíguo. Neste ponto, a resolução de sobrecarga não pode acontecer com base na seqüência de conversão mais curta. No entanto, sequências de igual conversão dadas, a resolução de sobrecarga prefere funções não-molde, ou seja no check(B*, int).

Você agora vê por que não importa que a herança seja privada: essa relação serve apenas para eliminar a no check(Host<B,D>(), int())resolução de sobrecarga antes que a verificação de acesso aconteça. E você também vê por que operator B* constdeve ser constante: do contrário, não há necessidade da Host<B,D> -> Host<B,D> constetapa, nenhuma ambigüidade e no check(B*, int)sempre seria escolhido.

O privatebit é completamente ignorado por is_base_ofporque a resolução da sobrecarga ocorre antes das verificações de acessibilidade.

Você pode verificar isso simplesmente:

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
}

O mesmo se aplica aqui, o facto de Bser uma base privada não impede a realização da verificação, apenas impediria a conversão, mas nunca pedimos a conversão efectiva;)

Possivelmente tem algo a ver com o pedido parcial em relação à resolução de sobrecarga. D * é mais especializado do que B * no caso de D derivar de B.

Os detalhes exatos são bastante complicados. Você tem que descobrir as precedências de várias regras de resolução de sobrecarga. A ordenação parcial é uma. Comprimentos / tipos de sequências de conversão são outro. Finalmente, se duas funções viáveis ​​forem consideradas igualmente boas, os não modelos são escolhidos em vez dos modelos de função.

Nunca precisei pesquisar como essas regras interagem. Mas parece que o pedido parcial está dominando as outras regras de resolução de sobrecarga. Quando D não deriva de B, as regras de ordenação parcial não se aplicam e o não modelo é mais atraente. Quando D deriva de B, a ordenação parcial entra em ação e torna o modelo de função mais atraente - como parece.

Quanto ao fato de a herança ser privada: o código nunca pede uma conversão de D * para B * que exigiria herança pública.

Seguindo sua segunda pergunta, observe que se não fosse por const, o Host seria mal formado se instanciado com B == D. Mas is_base_of é projetado de forma que cada classe seja uma base de si mesma, portanto, um dos operadores de conversão deve seja const.