Supongamos que tengo:objeto C++ tamaños
struct Foo: public Bar {
....
}
Foo introduce ningún nuevo miembro varaibles. Foo solo presenta un grupo de funciones miembro & funciones estáticas. ¿Alguna parte del estándar C++ me garantiza ahora que:
sizeof(Foo) == sizeof(Bar)
?
Gracias!
lo que podía pensar de al menos un escenario en el que sizeof(Foo) != sizeof(Bar):
class Bar {
public:
int m_member;
};
class Foo : Bar {
virtual ~Foo();
};
Foo tendrá un puntero vtable mientras que Bar no y el tamaño del primero será una palabra más grande que Bar. En 32 bits de depuración MSVC2010:
sizeof(Foo) - 8
sizeof(Bar) - 4
EDITAR Esto es válido para estructuras, así como clases, me volvió a ejecutar la prueba para confirmar que.
@Betamoo: Me gustaría escuchar las diferencias y cómo se relacionan con esta respuesta. – tiftik
En C++, la única diferencia entre las estructuras y las clases es el alcance de acceso predeterminado. - con una adición, aunque realmente no importe, el lenguaje le pide que se refiera a la misma construcción consistentemente. No puede declarar "clase Foo", luego "struct Foo". Al menos, si lo hace, supondrá que son lo mismo y (normalmente) advierte sobre declaraciones inconsistentes. –
@Betamoo: C++ no tiene "estructuras". Todo es una clase, incluso si se declara con la palabra clave 'struct'. – AnT
Ciertamente no, especialmente si alguna de las funciones en cualquiera de sus clases es virtual. Mientras estándar de C++ no garantiza esto, que tiene funciones virtuales es casi seguro que cambiar el tamaño de los objetos (a causa de v-tables.)
pero él está hablando de estructuras, no de clases ... – Betamoo
Las estructuras son las mismas que las clases en C++, la única diferencia es que el acceso por defecto es público, no privado. –
Sí, si son tipos de POD. Los tipos de POD están garantizados para ser compatibles con el diseño (es decir, puede memcpy de uno a otro) si tienen miembros compatibles con el diseño en el mismo orden. Como una subclase tiene automáticamente todos los miembros de su clase base en el mismo orden y, en este caso, no otros, serán compatibles con el diseño y, por lo tanto, del mismo tamaño. Ver la sección 9.3 de la especificación.
Tenga en cuenta que con el fin de ser tipos POD que no deben tener funciones virtuales (entre otros requisitos)
EDITAR
El último borrador de la norma ha dividido a los requisitos para los tipos de POD en dos conjuntos: triviales clases y diseño estándar clases. POD clases son las que son a la vez trivial y diseño estándar, y creo que para la Garantía sizeof desea, simplemente estar disposición estándar basta - No necesitan también ser trivial (y por lo tanto POD) clases. Los requisitos para disposición estándar de la especificación son:
A clase estándar-layout es una clase que:
- no tiene miembros de datos no estáticos de la clase de tipo no estándar-layout (o array de tales tipos) o referencia,
- no tiene funciones virtuales (10.3) ni clases base virtuales (10.1),
- tiene el mismo control de acceso (Cláusula 11) para todos los miembros de datos no estáticos,
- no tiene clases de bases no estándar de diseño,
- o bien no tiene ninguna miembros de datos estáticos en la clase más derivada y como máximo una clase base con miembros de datos no estáticos, o no tiene clases base con miembros de datos no estáticos, y
- no tiene clases base del mismo tipo que primer miembro de datos no estáticos.108
No creo que la garantía sea válida si hay funciones de miembros, ¿o sí? Ciertamente, el ejemplo de la clase base sin miembros virtuales y la subclase con virtuales sugeriría que no. –
Los tipos de POD pueden tener funciones de miembros. Sin embargo, no pueden tener funciones de miembros virtuales. No estoy convencido de que un tipo con un tipo base pueda considerarse un POD, ¿no es así? – Stewart
@Mark, @Stewart: Un POD puede tener funciones miembro, pero no una ** base, ** copia constructor, destructor, función virtual, miembro de datos no públicos o un miembro que no cumple estos requisitos. – Potatoswatter
También tenga en cuenta que el 'Bar' tha t está contenido en 'Foo' puede tener un tamaño diferente al' Bar' que no está contenido en un 'Foo'. Por ejemplo, una optimización común es hacer que las clases base tengan un tamaño cero si están vacías, pero distintas de cero si no están contenidas como clases base (como lo requiere C++). –