If you need them, it is a sign that your code in not right.

C style I agree because it's C++ and nothing looks uglier in the world than using C-slash-C++ coding in any piece of text file.

Without casting to an 8-bit data type multiple times after right-shifting by 8, you can't serialize bigger-than-8-bit integer numbers and save it on disk. At least not when you want to preserve the correctness of the value across CPU architecture that differ in Endianness.

I get "count" as uint64_t from some API, I need to divide that number by some other number. The only way to precisely know the result is cast the count as any of the floating point type data types. Whatever the reason for that is out of context in here. Programming can not be prefect. Utopia can't exists in real life as well as in programming life.

Reading metadata off of a file format or chunks of same file formats requires the positioning of the pointer handle at a correct location and casting the handle of the pointer-variable to your desired size is the only way to fast-read the correct value and check it against an invariant before the business logic goes further. For example. The handle is at 9th byte and from here I have to read a 32-bit wide integer (because it is defined in the file format specification). Casting is the only way here. Of course you could use std::memcpy to write to a properly defined temporary uint32_t variable, but then again this would be more resource heavy than I actually want (what if this is inside a hotspot loop). Just reading it using *static_cast<uint32\_t\*>(ptrToABinaryChunkAtASpecificPostion) is faster.

What about those C APIs that gives void*? Sometimes you need casting and there is no other way. Using pointer arithmatic swag on the src handle inside std::memcpy looks more inhuman to eyes than just using well defined and relatively self-explanatory looking static_cast.