De la discusión de esta pregunta.¿Cómo se implementa el acceso para variables privadas en C ++ bajo el capó? Presenté una variación: en lugar de acceder a un miembro de datos privados, ¿se pueden llamar funciones de miembros privados mediante la conversión y la confianza en la compatibilidad de diseño?

Algún código (inspirado en la columna de Herb Sutter).Usos y abusos de los derechos de acceso )

#include <iostream>

class X 
{ 
public:
  X() : private_(1) { /*...*/ }

private: 
  int Value() { return private_; }
  int private_; 
};

// Nasty attempt to simulate the object layout
// (cross your fingers and toes).
//
class BaitAndSwitch
    // hopefully has the same data layout as X
{   // so we can pass him off as one
public:
  int Value() { return private_; }
private:
  int private_;
};

int f( X& x )
{
  // evil laughter here
  return (reinterpret_cast<BaitAndSwitch&>(x)).Value();
}

int main()
{
    X x;
    std::cout << f(x) << "\n"; // prints 0, not 1
    return 0;
}; 

Nota: esto funciona (al menos en Ideone)! ¿Hay alguna manera la nuevaEstándar C ++ 11 da ungarantizado o al menos undefinida por la implementación ¿Cómo evitar el control de acceso confiando en la compatibilidad de diseño y reinterpret_cast / static_cast?

EDITAR1: salida enIdeone

EDIT2: En la columna de Sutter, enumera dos razones por las que no se garantiza que el código anterior funcione (aunque funciona en la práctica)

a) No se garantiza que los diseños de objetos de X y BaitAndSwitch sean los mismos, aunque en la práctica probablemente siempre lo serán.

b) Los resultados de reinterpret_cast no están definidos, aunque la mayoría de los compiladores le permitirán tratar de usar la referencia resultante de la forma en que lo hizo el pirata informático.

¿El nuevo estándar de C ++ 11 ahora ofrece estas garantías de diseño / reinterpretación?