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 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 encontraran 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 especifica y/o un sistema operativo puede tener soporte especifico 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 prohibir hacer cosas salvajes. Solo le proporciona una alternativa mucho más fácil, y 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, así en caso de tener que portarlo se podrá concentrar en ella.