C++: justificación detrás de la regla de ocultación

No conozco el razonamiento original, pero como hide o not hide son elecciones igualmente malas wrt. para las funciones, supongo que la razón es tener reglas uniformes: las mismas que para los nombres definidos en ámbitos de llaves anidadas.

El ocultamiento te ayuda de alguna manera.

Agregar un método a una clase base por defecto no afectará la resolución de sobrecarga para una clase derivada.

Y no se encuentra en conflicto con la resolución de sobrecarga por algún percance dirigiendo su llamada con say argument false, a un método de clase base con argumento formal void*. esas cosas.

Salud y hth.,

Estoy seguro de que he visto este caso ofrecido por un pez gordo de C++, no estoy seguro de cuál:

struct Base {
    void f(const Base&);
};

struct Derived : Base {
    using Base::f;
    void f(double);
};

int main() {
    Derived d;
    d.f('a'); // calls Derived::f
}

Ahora, agregue void f(int); a Base, y el significado de los cambios principales - llama a Base::f porque int es una mejor coincidencia para char - es una promoción de enteros en lugar de una conversión estándar.

No está claro si ese cambio a la base realmente sería destinado por el programador para capturar llamadas con char, por lo que requerir using para ser explícito significa que el comportamiento predeterminado es que el cambio no afecta el código de llamada. Creo que es una llamada marginal, pero creo que el comité decidió que las clases base en C++ eran lo suficientemente frágiles como son, sin esto también: -)

No hay necesidad de una palabra clave "hide" porque no hay un caso comparable para ocultar "f" de la Base cuando no está sobrecargada en Derivada.

Por cierto, he elegido los tipos, y char es deliberadamente incongruente. Puede obtener casos más sutiles con int vs unsigned int en lugar de int vs char.

Otra razón para ocultar la función miembro de la clase base (con el mismo nombre pero diferentes firmas) podría deberse a la ambigüedad causada por parámetros opcionales. Considere el siguiente ejemplo:

#include <stdio.h>

class A
{
public:
    int foo(int a, int b=0)
    {
        printf("in A : %d, %d\n", a, b);
    }
};

class B : public A
{
public:
    int foo(int a)
    {
        printf("in B : %d\n", a);
        foo(a); //B:foo(a) will be called unless we explicitly call A:foo(a)
        foo(a, 1); // compile error: no matching function for call to B:foo(int&, int)
    }
};


int main()
{
    B b;
    b.foo(10);
    return 0;
}

Si el método foo en la clase base no se hubiera ocultado, no sería posible para el compilador decidir si se debe llamar a A::foo o B::foo ya que la siguiente línea coincide con ambas firmas:

foo(a);

Probablemente, la razón es la especialización de plantillas. Les doy un ejemplo:

template <int D> struct A { void f() };

template <> struct A<1> { void f(int) };

template <int D>
struct B: A<D>
{
  void g() { this->f(); }
};

La clase B de la plantilla tiene un método f(), pero hasta que no cree una instancia de la clase B no conoce la firma. Así que la llamada this->f() es en cualquier momento "legal". Tanto GCC como CLang no informan de errores hasta que crea la instancia. Pero cuando llamas al método g() en una instancia B<1> indican el error. Por lo tanto, la regla de ocultación se mantiene más simple para verificar si su código es válido.

I reporta la última parte del código usado en mi ejemplo.

int main (int argc, char const *argv[])
{
  B<0> b0; /* valid */
  B<1> b1; /* valid */

  b0.g(); /* valid */
  b1.g(); /* error: no matching function for call to ‘B<1>::f()’ */

  return 0;
}