C++ ¿Es privado realmente privado?

Question

Estaba probando la validez del private especificador de acceso en C++. Aquí va:

Interfaz:

// class_A.h 

class A 
{ 
public: 
    void printX(); 
private: 
    void actualPrintX(); 
    int x; 
}; 

Implementación:

// class_A.cpp 
void A::printX() 
{ 
    actualPrintX(); 
} 

void A::actualPrintX() 
{ 
    std::cout << x: 
} 

Construí esto en una biblioteca estática (.a/lib). Ahora tenemos un par class_A.h y classA.a (o classA.lib). Edité class_A.h y eliminé el private: de él.

Ahora en otro classTester.cpp:

#include "class_A.h" // the newly edited header 

int main() 
{ 
    A a; 

    a.x = 12;   // both G++ and VC++ allowed this! 
    a.printX();   // allowed, as expected 
    a.actualPrintX(); // allowed by G++, VC++ gave a unresolved linker error 

    return 0; 
} 

Yo sé que después de la manipulación de cabecera de una biblioteca de todas las apuestas están apagadas (quiero decir, la integridad del sistema, etc.) Aunque el método siendo hacky, ¿es realmente ¿permitido? ¿Hay alguna manera de bloquear esto? ¿O estoy haciendo algo mal aquí?

Answer 1

private es no un mecanismo de seguridad. Es una forma de comunicar intenciones y ocultar información que otras partes de su programa no necesitan conocer, lo que reduce la complejidad general.

Tener dos diferentes archivos de cabecera no es compatible con los estándares, por lo que técnicamente usted está entrando en territorio comportamiento indefinido, pero en la práctica, ya que ha encontrado, la mayoría de los compiladores no les importa.

Answer 2

No. El control de acceso privado está ahí para evitar que USTED haga cosas estúpidas, no como un mecanismo de seguridad para evitar que otros accedan a sus datos o funciones. Hay muchas, muchas formas de evitarlo.

Answer 3

No hay implementación A :: actualPrintX en ninguna parte. Ese es su error de enlazador.

Answer 4

Usted ha desviado más allá de lo que está permitido en C++, así que lo que estás haciendo no está permitido - pero por supuesto que puede funcionar en algunos compiladores en algunas situaciones.

En concreto, está infringiendo el One Definition Rule.

Este article de Herb Sutter lo explica muy bien, sino que también proporciona una forma legal y portátil de eludir el sistema especificador de acceso.

Answer 5

Lo intenté. Este es un nm de un programa que escribí teniendo una prueba de clase con un método privado y uno privado.

0000000100000dcc T __ZN4Test3barEv 
0000000100000daa T __ZN4Test3fooEv 

Como puede ver, la firma es exactamente la misma. El enlazador no tiene absolutamente nada para distinguir un método privado de uno público.

Answer 6

Estoy de acuerdo con la mayoría de las otras respuestas.

Sin embargo, me gustaría señalar que es perfectamente aceptable para un compilador organizar físicamente los miembros de manera diferente cuando elimina ese private. Si funciona, eso es suerte. No puedes contar con eso Si ambos lados no usan la misma declaración, en realidad no están usando la misma clase.

Answer 7

Como nadie ha mencionado una forma de bloquear esto ...Una forma posible de bloquear el acceso a miembros privados es declararlos como un tipo interno independiente no visible fuera del archivo. Por supuesto, si desea proporcionar acceso explícito a este interno, entonces deberá proporcionar la declaración interna. Eso también se hace comúnmente usando un encabezado interno que contiene ese tipo.

Nota: Deberá realizar un seguimiento de la asignación/liberación de ese objeto interno en este ejemplo. Hay otras formas de hacerlo que no requieren esto.

// class_A.h 
class A { 
public: 
    void printX(); 
private: 
    void *Private; 
}; 

// class_A.cpp 
class A_private { 
    void actualPrintX(); 
    int x; 
}; 

void A::printX() { 
    reinterpret_cast<A_private *>(Private)->actualPrintX(); 
} 

void A_private::actualPrintX() { 
    std::cout << x: 
} 

Answer 8

En la mayoría de los casos, ni siquiera tiene que editar el archivo de encabezado para hacer públicos los miembros privados. Puedes hacer esto con el preprocesador. Algo como esto:

//"classWithPrivateMembers.hpp" 
class C 
{ 
private: //this is crucial for this method to work 
    static int m; 
}; 

int C::m = 12; 

y luego, esto va a funcionar:

#define private public 
#include "classWithPrivateMembers.hpp" 
#undef private 

int main() 
{ 
    C::m = 34; // it works! 
} 

Answer 9

Tenga en cuenta también que cuando se cambia el acceso de un miembro variable, el compilador puede colocarlo en un desplazamiento diferente dentro de la clase objeto. El estándar permite a los compiladores una gran cantidad de libertad en la reorganización de los miembros (al menos dentro del mismo nivel de acceso, creo).