Digamos que una clase baseA define un miembro protegido. Una clase derivadaB usa este miembro.

class A
{
public:
  A(int v) : value(v) { }

protected:
  int value;
};

class B : public A
{
public:
  B(int v) : A(v) { }
  void print() const;
  void compare_and_print(const A& other) const;
};

La funciónB::print solo toma el valor del miembro actual y lo imprime:

void B::print() const
{
  std::cout << "Value: " << value << "\n";
}

La otra función miembro,B::compare_and_print, toma una instancia deA, comprueba sus valores e imprime el máximo de ambos:

void B::compare_and_print(const A& other) const
{
  auto max_value = std::max(value, other.value);
  std::cout << "Max value: " << max_value << "\n";
}

Siother fueron una instancia de la claseB, esto no sería un problema. Pero a la función le gustaría trabajar con cualquier tipo deA instancias. Esto desafortunadamente no se compila. Esto es lo que dice clang sobre esto:

test.cpp:27:42: error: 'value' is a protected member of 'A'
  auto max_value = std::max(value, other.value);
                                         ^
test.cpp:9:7: note: can only access this member on an object of type 'B'
  int value;
      ^
1 error generated.

Esta restricción me suena contra-intuitiva. Sin embargo, no voy a disputar el estándar C ++ sobre esto (sin embargo, estoy interesado en la razón detrás de esta decisión).

Mi problema es que en mi proyecto realmente tengo este tipo de caso de uso: una clase derivada tiene un método que toma una instancia de la clase base y necesita acceder a un miembro protegido del objeto recibido.

La solución más fácil, la que implementé actualmente, es agregar una función de miembro público a la clase base, que devuelve el miembro protegido. Esta solución no me satisface completamente porque me gustaría evitar exportar el miembro de esta manera.

¿Cómo puedo habilitar el uso del miembro protegido de la clase base por la clase derivada sin exportar el miembro a través de la API?

EDITAR: Algunas preguntas relacionadas son:

La respuesta que me gustaría tener es la explicación de un patrón de diseño para resolver este problema sin exponer el miembro protegido al código externo (dondeexterno significa, código que no es parte del marco que define estas clases).

Podría ser que tal patrón no pueda existir, lo reconozco.