I'm not sure how to do this. I have ints, and one of them I want to read as a float with the same exactly hexadecimal value. In other words if the integer is 0x3F000000, I want the float value to also be 0x3F000000 (or 0.5 in decimal format). I haven't found a way to do this. Obviously casting alone doesn't work, so I'm stuck.

I've never heard of memcpy. But I did a quick search for it on Google and found some documentation on how to use it.

Thanks for the tip!

C Unions will also do this as well:

union Multitype {
    int int_mode;
    float float_mode;
};

// inside of your code

union Multitype myType;
myType.int_mode = 0x3F000000;
float myFloat = myType.float_mode;

My vote goes to reinterpret casts but make sure that all the bits for the sign, mantissa, etc. line up.

http://en.wikipedia.org/wiki/IEEE_754

If you are writing the ints to a file or sending down a network, don't forget to take into account the differences between big-endian and little-endian machines when designing a file-format.

AE.

What? Explain. So far as I can tell, none of the code posted in this thread is in any particular danger of not accomplishing its purpose due to agresive optimizers. It might not do exactly what it's supposed to do if floats aren't IEEE format 32 bit floats or ints aren't 32 bits, but that's also true of unions, and has little or no relationship to the optimizer. Indeed, I can not think of any reason why the union based version would have any advantage unless ints were larger than floats on the target platform (I don't think such a platform exists, though I believe the spec allows it, but that's independent of optimizer anyway).

This makes perfect sense to me.

This does not immediately make sense to me, though it calls to mind vague memories with obscure NaN issues. Googling for "canonicalizing NaN" found no results. I vaguely recall x86s changing some NaNs to other NaNs (ie still NaN but not binary identical to the previous state) if they aren't passed by reference (or conceivably even if they are, if the compiler is feeling obnoxious)... is that what you're referring to?

I usually don't mind platform dependence when the "platform" in question includes the compilers of MS, GNU, and Intel, and the instruction sets of x86, x86-64, PPC, and most other modern general purpose CPUs (edit: and the OSes of windows and linux and OS X). But, in this particular case I added the qualifier of "due to agresive optimizers" to specify that I wasn't counting circumstances where the code failed due to other reasons like lack of IEEE compliant floating point representation.

Hm... yeah, I guess the stuff added in C99 allows pointer casts to optimize weirdly. Presumably recent versions of the C++ spec have something similar permitting the the compiler to be compliant while optimizing reference casts weirdly. I believe that does not apply to reinterpret_cast<> versions. Though, by a worse-case literal reading of the standard, I guess the implementation of reinterpret_cast<> is basically undefined.

However, despite you being correct, I don't really agree : ). Just as I use "kilobyte" to refer to 1024 bytes instead of 1000 bytes that some standards body has defined it to mean (the standards body decided that 1024 bytes is a "kibibyte" instead), so do I interpret "C" and "C++" to be more or less the common elements of C/C++ compilers (particularly recent gcc, MSVC, and Intel-C versions, particularly for IA16, IA32, x86-64, PPC, and ARM) and my expectations of what those common elements might be in the future. The C/C++ standard permits compilers to assume that that incompatible pointer types point at different memory, but I operate under the assumption that this only applies if it is non-trivial for the compiler to figure out that the pointers are identical at compile time (often because of a function call boundary between the cast and the dereference, though plenty of other reasons apply too).
(now watch someone compile the above snippets on some gcc version I don't have installed and get nonsense results, proving me wrong)

Ah, well, now I know what you were saying. Dunno how many people around here are likely to understand "canonicalizing NaN", but there's probably someone besides me who scratched his head.

Umm...

Why? Why would you want to do that?

float array[100];
unsigned checksum = 0;
for (int i = 0; i < 100; ++i) {
  checksum = 33*checksum + *(unsigned*)(&array<i>);
}

Interesting. On gcc 3.4.2 on my computer, this works:

void checksum() {
  float array[100];
  for (int i = 0; i < 100; ++i) {
    array<i> = rand() / 65535.;
  }
  unsigned checksum = 0;
  for (int i = 0; i < 100; ++i) {
    checksum = 33*checksum + *(unsigned*)(&array<i>);
  }
  printf("checksum: %d\n", checksum);
}

this does NOT work on my gcc version (due to alliasing issues):

void checksum() {
  float array[100];
  unsigned checksum = 0;
  for (int i = 0; i < 100; ++i) {
    array<i> = rand() / 65535.;
    checksum = 33*checksum + *(unsigned*)(&array<i>);
  }
  printf("checksum: %d\n", checksum);
}

However, wrapping the conversion appears to fix it:

inline unsigned int binfloat2int_ref_cast(float f) {
  return (unsigned int&)f;
}
void checksum() {
  float array[100];
  unsigned checksum = 0;
  for (int i = 0; i < 100; ++i) {
    array<i> = rand() / 65535.;
    checksum = 33*checksum + binfloat2int_ref_cast(array<i>);
  }
  printf("checksum: %d\n", checksum);
}

Casting to a union pointer instead of an integer pointer also appeared to fix the issue.
All versions of the code worked fine on MSVC 7.1.
Of course, sane people would probably make some effort to avoid the issue out of uncertainty just what future compilers will do, or even what current compilers might concievably do if it was the wrong phase of the moon.