|reinterpret_cast<> allows to come back to the previous data type?|
generally this is done on either very low level types like int, or in a known easy reshape.
take a look at what it is DOING.
this cast takes the RAW BYTES of an object and says "hey, that pile of bytes is a whazzit". Later, you can just cast the same bytes back to the original, and now its a widget instead of a whazzit, ok: the compiler can deal with that.
why would you do such a thing?
this is common in file and network 'serialization' where generic functions (like file.write) work off chunks of bytes, so you cast your object to a char pointer(bytes!) and get its size (sizeof) and say hey, go write the bytes from here to here to the disk or network. When you later read that file back, you cast the bytes you read back into your class.
for another example, just being funny the other day, I cast a double to an integer, did a bitwise operation to knock off the last wad of significant binary digits, and cast it back to double. Not something one normally would do, but these are the kinds of things you are doing with reinterpret casting: forcing bytes to mean what you want them to mean for a moment. Another example, if you were copying C style strings in a performance oriented program, and you padded all your string sizes to be a multiple of 8, then you can cast and copy them as integers 8 times faster than copying them one byte at a time. (its likely that your compiler library already does this, but its an example so go with me here).
R-cast is 'the weeds'. you should know what it does, and how to use it for writing a binary file or whatever, but don't get caught up here trying to figure out exotic ways to reshuffle bytes. Once in a very rare while you can do something really productive here; most of the time its either unnecessary hackery or exceedingly simple (like the write() example).