You should never, EVER fwrite a struct to begin with.

That still doesn't solve his enum problem, and no, it will not be done the same way on all systems, perhaps. GCC might do it the same way though. The Win32 API's enums have a FORCE_DWORD enum, and they define it like so:

enum MyEnum {
  value = 0,
  value2 = 1,
  //etc
  FORCE_DWORD = 0xFFFFFFFF
};

Or something like that. That would make sure it is DWORD-sized or bigger I'd think, and not the size of a DWORD.

Really you can't rely on sizeof(int) being the same and such. This is one of the things that suck about C++. You could try using some of the C99 types if your compiler supports them (I think Boost provides a wrapper for compilers that don't support it). And I believe some of the C99 types guarantee a variable of an exact size.

why do you say to not fwrite a struct?
i think that its one of the fastest way to write down a complicated data sequence

If you try compiling your program with another compiler (or different version of your current compiler), you'd better hope and pray those variables are the same size, use the same padding, etc. Otherwise, you're boned. Member by member is much safer. Slower, but safer.

It is the fastest way to write down a complicated structure. Sometimes it's also the only practical way to do so.

It happens to also be really nasty in C / C++:

a. The sizes of primitive items within a struct vary depending upon your platform, so files produced this way can't be shared across platform boundaries

b. On some platforms the compiler may add invisible "padding" bytes to your structures... this can reduce efficiency, and result in a lack or portability similar to sizes of primitives issue.

c. There tends to be endianness portability issues if you use any primitives larger than 1 byte.

d. If your struct contains pointers... well... you'll have to handle that specially of course.

e. If you're using C++ and your struct has a virtual method or somesuch, then the type data (vtable pointer) will be included as well, but it may result in nasty nasty stuff: the correct value might not even be portable between different runs on the same computer using the same compiler.

All that said, if you insulate your types by defining intermediates ala SDLs Uint32, C99s uint32_t or whatever, and you're carefully about alignment issues, and you don't use anything virtual, and you handle the endianness issues somehow, it IS possible to write fairly portable code that does raw fwrites with structs.

I don't know why you would cast to 64-bit integers. That's pretty excessive for an enum. Depending on your enum you should be able to cast to unsigned char or unsigned short?