Advertencia: Post para coders. Puede producir dolor de cabeza. Tambi\u00e9n puede contener informaci\u00f3n horriblemente equivocada, en cuyo caso se ruegan correcciones en los comentarios.
\nHoy me he pasado un buen rato preguntandome por qu\u00e9 no funcionaba esto (recemos para que el WordPress no me destroce demasiado el codigo :P) :<\/p>\n
#include <cstdio>\nint main() \n{\n int i; float f=1.0f;\n i = *reinterpret_cast<float*>(&f);\n printf(\"i = 0x%0x\\n\", i);\n return 0;\n}\n<\/pre>\nCompilando sin optimizaci\u00f3n funcionaba como se esperaba, y con optimizaci\u00f3n daba un resultado distinto. Al principio pens\u00e9 “un error del gcc, seguro”, pero me he puesto a buscar y resulta que no es un bug, sino una feature<\/a>. ISO C tiene reglas en contra del aliasing de punteros que dicen que acceder a una variable mediante un puntero de un tipo incompatible es ilegal, asi que al activar las optimizaciones asume que esas cosas no pasan y genera un resultado incorrecto. Una solucion t\u00ed\u00adpica es el clasico hack<\/em> en el que se define una union de un int y un float, se escribe en un miembro y se lee en el otro, pero creo que el estandar dice que en este caso el resultado est\u00e1 definido por la implementaci\u00f3n. Mala cosa. Tambien he leido por ahi que una buena opcion es usar memcpy, hacer una copia de lo que sea a otra posicion de memoria y te olvidas del aliasing.<\/p>\nMas cositas. Programando en la uni el otro dia pensamos en lo bonito que seria disponer de tipos de tama\u00f1o fijo, como los uint8, int32, que todos hemos usado alguna vez. Pues bien, en C existen y en C++ no. Ahora alguien se puede preguntar “\u00bfpero c\u00f3mo? si C es un subconjunto de C++!”, pero esto no solo no es cierto, sino que desde la aparici\u00f3n de C99<\/a> hay incluso m\u00e1s diferencias<\/a> (el estandar de C++ es del 98). En este caso, C99 especifica una cabecera stdint.h<\/a> que define tipos con nombres como int8_t.<\/p>\n