Casi siempre compilamos el tiempo. Sin embargo, los siguientes ejemplos podrían ser de su interés:
char c[100];
sizeof(c); // 100
char* d = malloc(100);
sizeof(d); //probably 4 or 8. tells you the size of the pointer!
BaseClass* b = new DerivedClass();
sizeof(b); //probably 4 or 8 as above.
void foo(char[100] x) {
sizeof(x); //probably 4 or 8. I hate this. Don't use this style for this reason.
}
struct Foo {
char a[100];
char b[200];
};
sizeof(struct Foo); //probably 300. Technically architecture dependent but it will be
//the # of bytes the compiler needs to make a Foo.
struct Foo foo;
sizeof(foo); //same as sizeof(struct Foo)
struct Foo* fooP;
sizeof(fooP); //probably 4 or 8
class ForwardDeclaredClass;
ForwardDeclaredClass* p;
sizeof(p); //4 or 8
ForwardDeclaredClass fdc; //compile time error. Compiler
//doesn't know how many bytes to allocate
sizeof(ForwardDeclaredClass); //compile time error, same reason
Una excelente prueba de lo ridículamente perversas que son las VLA. En mi opinión, el consumo explícito de la pila de longitud variable ('alloca') es mucho mejor. – valdo
@valdo, no veo lo que se supone que debe probar esto. Parece normal que 'sizeof' un objeto que se dimensiona dinámicamente en el momento de la ejecución tenga que evaluarse en el momento de la ejecución. Y en comparación con otros mecanismos como 'alloca' (que ni siquiera está estandarizado y no tiene alcance) o' malloc' que ambos no saben nada sobre el tamaño de los objetos que crean no es muy útil. –
@Jens Gustedt: Lo siento, quise decir * ejemplo *, no a * prueba *. 'alloca' no necesita un freeing/scope explícito. El código generado es (más o menos) idéntico a los VLA: mover el puntero de pila + probar la memoria de pila al cruzar el límite de página. Yo personalmente uso 'sizeof' muy agresivamente en meta-programación (temapltes y etc.), y me gustaría estar 100% seguro de que lo que está dentro de' sizeof' nunca será evaluado en tiempo de ejecución. – valdo