memoria c ++ en el conjunto de objetos de clase

Tengo una clase como esta:

class Object { public: unsigned char data[8]; // other variables // functions etc... }; 

La pregunta es: ¿están todos los miembros del objeto almacenados en el mismo lugar en la memoria en relación con el objeto? Entonces, si tengo una matriz: matriz de objeto [3], dado un puntero char* data_ptr = array[0].data , ¿ data_ptr + (sizeof(Object)) entonces siempre apunta a la matriz [1] .data?

(He leído un par de preguntas y respuestas sobre cómo podría haber relleno entre los miembros de datos de las clases y las estructuras, pero no creo que respondan mi pregunta).

Gracias de antemano, Ben

sizeof Object ya incluye todo el relleno interno de la clase Object . Incluyendo cualquier relleno en su extremo. Las matrices no permiten ningún relleno adicional. Por lo tanto, es cierto que data_ptr + sizeof Object tendrá la dirección de array[1].data .

Sin embargo, no estoy seguro de si esto está realmente permitido. Es decir, se puede permitir que el comstackdor asum que nunca agrega un valor mayor que 8 (el tamaño de los data de la matriz miembro) a la array[0].data , y por lo tanto puede aplicar optimizaciones que fallan si viola las reglas. Es decir, su código podría mostrar un comportamiento indefinido (que es el término estándar para “el comstackdor tiene permitido hacer cualquier cosa en este caso”).

Sin embargo, dado que está utilizando un puntero a char , para el cual hay más reglas permisivas (puede hacer muchas cosas con char* que no podría hacer con tipos generales), puede ser que en realidad este sea un comportamiento definido.

Si el objective de tu pregunta es entender cómo están las cosas en la memoria, entonces es aceptable.

Pero si quiere hacer eso de verdad : lo que quiere hacer es criminal contra todos sus colegas.

La forma correcta de revisar la colección en C ++ es no usar una matriz, sino un std :: vector u otra colección estándar si es realmente necesario . Ya no deberíamos usar C aritmética, sino acceder a los elementos de la colección de vectores a través de un iterador. Esa es la razón de la biblioteca estándar de C ++ 🙂

Creo que la respuesta es “Tal vez”, lo que significa que no debes apostar en esto. La mejor manera sería jugar en su depurador IDE buscando direcciones de memoria. Encontrarás que esto podría fácilmente desecharse cuando introduzcas tener miembros y métodos que el comstackdor pueda optimizar. Por ejemplo, cualquier constante o un método que no acceda a ningún miembro que pueda ser estático. Ex:

 void Object::doSomething() {std::cout << "something\n" << std::endl;} 

Creo que esto realmente se optimiza en la asignación estática porque recientemente aprendí que ((Object)NULL).doSomething(); en realidad funciona sin un SEGURO hasta que introduce una variable miembro para Object .

Hay muchos factores que deciden el tamaño de un objeto de una clase en C ++. Estos factores son: – Tamaño de todos los miembros de datos no estáticos – Orden de los miembros de datos – Alineación de bytes o relleno de bytes – Tamaño de su clase base inmediata – La existencia de funciones virtuales (Polimorfismo dynamic mediante funciones virtuales). – Comstackdor en uso – Modo de herencia (herencia virtual)

consulte aquí: http://www.cprogramming.com/tutorial/size_of_class_object.html

Sí, el diseño relativo a la dirección base del objeto será constante. Este es un requisito para el ABI. Cualquier espacio o relleno de objetos y matrices también está especificado por la ABI.