En el Capítulo 4 se dijo que una struct escrita para un compilador C y más tarde compilada en uno de C++ no cambiaría. Se refería básicamente a la estructura interna del objeto que surge de la struct, es decir, la posición relativa en memoria donde se guardan los valores de las diferentes variables. Si el compilador C++ cambiase esta estructura interna, entonces el código escrito en C que, imprudentemente, hiciese uso del conocimiento de las posiciones de las variables fallaría.

Cuando se empiezan a usar los especificadores de acceso, se cambia al universo del C++, y las cosas cambian un poco. Dentro de un «bloque de acceso» (un grupo de declaraciones delimitado por especificadores de acceso), se garantiza que las variables se encontrarán contiguas, como en C. Sin embargo, los bloques de acceso pueden no aparecer en el objeto en el mismo orden en que se declaran. Aunque el compilador normalmente colocará los bloques como los definió, no hay reglas sobre esto, pues una arquitectura hardware específica y/o un sistema operativo puede tener soporte específico para private y protected que puede requerir que estos bloques se coloquen en lugares específicos de la memoria. La especificación del lenguaje no quiere impedir este tipo de ventajas.

Los especificadores de acceso son parte de la estructura y no afectan a los objetos creados desde ésta. Toda la información de accesos desaparece antes de que el programa se ejecute; en general ocurre durante la compilación. En un programa en ejecución, los objetos son «zonas de almacenamiento» y nada más. Si realmente quiere, puede romper todas las reglas y acceder a la memoria directamente, como en C. C++ no está diseñado para impedirle hacer cosas insensatas. Sólo le proporciona una alternativa mucho más fácil y muy deseable.

En general, no es una buena idea hacer uso de nada que dependa de la implementación cuando se escribe un programa. Cuando necesite hacerlo, encapsúlelo en una estructura, de modo que los cambios necesarios para portarlo se concentren en un solo lugar.