significa - C++, ¿las funciones privadas realmente necesitan estar en el archivo de encabezado?

que significa header en programacion

Question

Siempre he pensado en los archivos de encabezado como una especie de ''interfaz pública'' que describe una clase, en cuyo caso sería mejor mantener los campos y las funciones privadas en el archivo cpp.

Entiendo que los campos privados deben estar en el encabezado para que otras clases puedan saber cuánta memoria consumirá una instancia de una clase, pero se me ocurrió que estaba a punto de escribir una función auxiliar privada, que esta función podría realizarse estática, en cuyo caso no era necesario que fuera "parte de la clase", podría ser una función normal en el archivo .cpp de la definición de la clase.

Entonces se me ocurrió que todas las funciones privadas podrían reescribirse para ser estáticas aceptando punteros / referencias a campos de clase en lugar de esperar que se definan en la clase.

Esto eliminaría la necesidad de declarar cualquier función privada en el archivo de encabezado.

Me gusta seguir las convenciones, por lo que ahora quiero preguntar, ¿se considera una convención establecida en C ++, que las funciones privadas no estáticas deben estar en el archivo de encabezado? ¿Qué pasa con las funciones estáticas o constantes estáticas?

EDITAR: Voy a poner un código para explicar a qué me refiero:

archivo .h:

#ifndef SOME_CLASS_H
#define SOME_CLASS_H
class SomeClass
{
private:
int x;
public:
void combineWithX(int y);
};
#endif

archivo .cpp

#include "SomeClass.h"
void someHelper(int* x)
{
*x = (*x) + 1;
}
void SomeClass::combineWithX(int y)
{
someHelper(&x);
x += y;
}

Tenga en cuenta que someHelper(int* x) en el archivo cpp hace referencia al miembro privado x en espíritu, pero no directamente, y por lo tanto no es necesario que aparezca en el encabezado. Me pregunto si este tipo de cosas se considera "mal estilo".

Answer 1

Estoy de acuerdo en que es un problema que los detalles de la implementación deban estar expuestos en un archivo de encabezado; Interfiere con la separación de interfaz e implementación.

Mover las funciones de ayuda privadas para que sean funciones libres en el archivo .cpp (supongo que eso es lo que quiere decir con "estática") no funcionará si esas funciones necesitan acceder a las variables de miembros privados.

Quizás te interese mirar el lenguaje pImpl (more)

Answer 2

Solo se necesita lenguaje idiomático

1. si necesita sacar las ''variables'' de miembros privados del encabezado público (para mantener la compatibilidad binaria de las nuevas versiones: si no sabe lo que eso significa, es probable que no sea una preocupación)
2. Si ese diseño lo hace más fácil de entender

Si solo desea mover "funciones" privadas de miembro fuera del encabezado público, usar una clase interna es suficiente. Esto no tiene penalización de redireccionamiento como el lenguaje PImpl.

archivo .h público

#ifndef SOME_CLASS_H
#define SOME_CLASS_H
class SomeClass
{
private:
struct Private;
int x;
public:
void combineWithX(int y);
};
#endif

en archivo .cpp

#include "SomeClass.h"
/** Declare all private member functions of SomeClass here
This class can access not only private members of SomeClass
but also friends of SomeClass. */
struct SomeClass::Private
{
static void someHelper(SomeClass& self)
{
self.x = self.x + 1;
}
};
void SomeClass::combineWithX(int y)
{
Private::someHelper(*this);
x += y;
}

SomeClass::Private puede tener cualquier número de funciones de ayuda que tengan acceso completo a todos los amigos / privados de SomeClass , sin tener que declarar ninguna de ellas en el archivo de encabezado.