¿Cómo funciona "is_base_of"?

¿Cómo funciona el siguiente código?

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. Tenga en cuenta que Bes una base privada. ¿Como funciona esto?

2. Tenga en cuenta que operator B*()es const. ¿Por qué es importante?

3. ¿Por qué es template<typename T> static yes check(D*, T);mejor que static yes check(B*, int);?

Nota : Es una versión reducida (se eliminan las macros) de boost::is_base_of. Y esto funciona en una amplia gama de compiladores.

Si estan relacionados

Supongamos por un momento que en Brealidad es una base de D. Luego, para la llamada a check, ambas versiones son viables porque Hostse pueden convertir en D* y B* . Es una secuencia de conversión definida por el usuario como se describe en 13.3.3.1.2from Host<B, D>a D*y B*respectivamente. Para encontrar funciones de conversión que puedan convertir la clase, las siguientes funciones candidatas se sintetizan para la primera checkfunción de acuerdo con13.3.1.5/1

D* (Host<B, D>&)

La primera función de conversión no es candidata porque B*no se puede convertir a D*.

Para la segunda función, existen los siguientes candidatos:

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

Esos son los dos candidatos a la función de conversión que toman el objeto host. El primero lo toma por referencia constante y el segundo no. Por lo tanto, el segundo es una mejor coincidencia para el *thisobjeto no constante (el argumento del objeto implícito ) por 13.3.3.2/3b1sb4y se usa para convertir a B*para la segunda checkfunción.

Si eliminara la constante, tendríamos los siguientes candidatos

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

Esto significaría que ya no podemos seleccionar por constness. En un escenario de resolución de sobrecarga normal, la llamada ahora sería ambigua porque normalmente el tipo de retorno no participará en la resolución de sobrecarga. Para las funciones de conversión, sin embargo, existe una puerta trasera. Si dos funciones de conversión son igualmente buenas, entonces el tipo de retorno de ellas decide cuál es la mejor según 13.3.3/1. Por lo tanto, si eliminara la constante, se tomaría la primera, porque B*convierte mejor a B*que D*a B*.

Ahora bien, ¿qué secuencia de conversión definida por el usuario es mejor? ¿El de la segunda o primera función de verificación? La regla es que las secuencias de conversión definidas por el usuario solo se pueden comparar si utilizan la misma función de conversión o constructor de acuerdo con 13.3.3.2/3b2. Este es exactamente el caso aquí: ambos usan la segunda función de conversión. Observe que, por tanto, la constante es importante porque obliga al compilador a tomar la segunda función de conversión.

Ya que podemos compararlos, ¿cuál es mejor? La regla es que la mejor conversión del tipo de retorno de la función de conversión al tipo de destino gana (nuevamente por 13.3.3.2/3b2). En este caso, D*convierte mejor a D*que a B*. ¡Así se selecciona la primera función y reconocemos la herencia!

Tenga en cuenta que dado que nunca necesitamos realmente convertir a una clase base, podemos reconocer con ello la herencia privada , porque si podemos convertir de una D*a una B*no depende de la forma de herencia de acuerdo con la4.10/3

Si no están relacionados

Ahora supongamos que no están relacionados por herencia. Así, para la primera función tenemos los siguientes candidatos

D* (Host<B, D>&) 

Y por el segundo ahora tenemos otro conjunto

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

Como no podemos convertir D*a B*si no tenemos una relación de herencia, ¡ahora no tenemos una función de conversión común entre las dos secuencias de conversión definidas por el usuario! Por tanto, seríamos ambiguos si no fuera por el hecho de que la primera función es una plantilla. Las plantillas son la segunda opción cuando hay una función que no es de plantilla que es igualmente buena de acuerdo con 13.3.3/1. Por lo tanto, seleccionamos la función sin plantilla (la segunda) y reconocemos que no hay herencia entre By D!

Averigüemos cómo funciona mirando los pasos.

Empiece por la sizeof(check(Host<B,D>(), int()))pieza. El compilador puede ver rápidamente que se check(...)trata de una expresión de llamada a función, por lo que debe realizar una resolución de sobrecarga check. Hay dos posibles sobrecargas disponibles template <typename T> yes check(D*, T);y no check(B*, int);. Si se elige el primero, obtienes sizeof(yes), elsesizeof(no)

A continuación, veamos la resolución de sobrecarga. La primera sobrecarga es una instanciación de plantilla check<int> (D*, T=int)y el segundo candidato es check(B*, int). Los argumentos reales proporcionados son Host<B,D>y int(). El segundo parámetro claramente no los distingue; simplemente sirvió para convertir la primera sobrecarga en una plantilla. Veremos más adelante por qué la parte de la plantilla es relevante.

Ahora mire las secuencias de conversión que se necesitan. Para la primera sobrecarga, tenemos Host<B,D>::operator D*una conversión definida por el usuario. Para el segundo, la sobrecarga es más complicada. Necesitamos una B *, pero posiblemente haya dos secuencias de conversión. Uno es via Host<B,D>::operator B*() const. Si (y sólo si) B y D están relacionados por herencia será la secuencia de conversión Host<B,D>::operator D*()+ D*->B*existir. Ahora suponga que D de hecho hereda de B. Las dos secuencias de conversión son Host<B,D> -> Host<B,D> const -> operator B* const -> B*y Host<B,D> -> operator D* -> D* -> B*.

Entonces, para B y D relacionados, no check(<Host<B,D>(), int())sería ambiguo. Como resultado, yes check<int>(D*, int)se elige la plantilla . Sin embargo, si D no hereda de B, entonces no check(<Host<B,D>(), int())no es ambiguo. En este punto, la resolución de la sobrecarga no puede ocurrir según la secuencia de conversión más corta. Sin embargo, dadas secuencias de conversión iguales, la resolución de sobrecarga prefiere funciones sin plantilla, es decir no check(B*, int).

Ahora ve por qué no importa que la herencia sea privada: esa relación solo sirve para eliminar la no check(Host<B,D>(), int())resolución de sobrecarga antes de que ocurra la verificación de acceso. Y también ve por qué operator B* constdebe ser constante: de lo contrario, no es necesario el Host<B,D> -> Host<B,D> constpaso, no hay ambigüedad y no check(B*, int)siempre se elegiría.

El privatebit es completamente ignorado por is_base_ofporque la resolución de sobrecarga ocurre antes de las comprobaciones de accesibilidad.

Puede verificar esto simplemente:

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 mismo se aplica aquí, el hecho de que Bsea ​​una base privada no impide que se lleve a cabo la verificación, solo evitaría la conversión, pero nunca pedimos la conversión real;)

Posiblemente tenga algo que ver con el ordenamiento parcial de la resolución de sobrecarga. D * es más especializado que B * en el caso de que D se derive de B.

Los detalles exactos son bastante complicados. Debe averiguar las precedentes de varias reglas de resolución de sobrecarga. El pedido parcial es uno. Longitudes / tipos de secuencias de conversión es otro. Finalmente, si dos funciones viables se consideran igualmente buenas, se eligen no plantillas en lugar de plantillas de funciones.

Nunca necesité buscar cómo interactúan estas reglas. Pero parece que el ordenamiento parcial está dominando las otras reglas de resolución de sobrecarga. Cuando D no se deriva de B, las reglas de ordenación parcial no se aplican y la no plantilla es más atractiva. Cuando D se deriva de B, el orden parcial se activa y hace que la plantilla de función sea más atractiva, como parece.

En cuanto a que la herencia sea privada: el código nunca solicita una conversión de D * a B *, lo que requeriría una herencia pública.

Siguiendo con su segunda pregunta, tenga en cuenta que si no fuera por const, Host estaría mal formado si se instancia con B == D. Pero is_base_of está diseñado de tal manera que cada clase es una base de sí misma, por lo tanto, uno de los operadores de conversión debe ser const.