Michael Lotz wrote: > Maybe let me extend the example: > > { > double someDouble = 0.0; > someDouble += 5.0; > int variable = *(int *)&someDouble; > someDouble -= 3.0; > return 0; > } > > Through strict aliasing rules, it's now like the compiler is allowed to > assume that something (someDouble in this case) cannot be referenced by > any pointer as there are no double pointers around. It therefore could > optimize the variable manipulation of someDouble. It would be allowed to > put the value into registers and keep it there (not writing the changed > value back to the memory location) until later on (which is quite > possible in that example as the variable is used again later in the code > and would profit from being still in the register). If this was the case, > then you'd obviously not get the expected value back when reading out > someDouble by casting it to an int and dereferencing it. You'd only get > back what is stored at the memory location and not what the real value at > this point in time (in the register) actually is. I don't really know if > this would happen with the example above of course, one would have to > look at the assembler output to check. Thanks a lot! That explains it perfectly well! Best regards, -Stephan