1. 25
  1.  

  2. 11

    This is also the cause of one of long running issues in Rust: https://github.com/rust-lang/rust/issues/27060.

    1. 3

      don’t agree: there are instances were it would be most useful to go from binary-stream to in memory representation without an intermediate ‘unpacking’ stage.

      or as james-micken’s puts it (the night watch):

      … You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. …

      1. 3

        Alpha, Itanic, PowerPC 600, MIPS R4000 in 2020??

        If we look at modern processors, this is not nearly as relevant:

        The ARMv8-A architecture allows many types of load and store accesses to be arbitrarily aligned.
        The Cortex®-A72 processor handles most unaligned accesses without performance penalties.
        However, there are cases which reduce bandwidth or incur additional latency, as described below.
        • Load operations that cross a cache-line (64-byte) boundary
        • Store operations that cross a 16-byte boundary

        and for something newer (A75), even the store situation is great:

        • In AArch64, all stores that cross a 128-bit boundary.

        1. 1

          Doesn’t 16 bytes equal 128 bits?

          1. 1

            Oh. Of course I misread this as 16 bits :D

        2. 2

          “Anybody who” is a horrible title.

          You absolute might do this if you’re using a struct to match byte-per-byte a binary data format such as sent via network (be mindful of endianness!) so you can reinterpret cast and use structures directly in your receive buffer, from a binary file, or maintaining backward compatibility with a struct from an existing API so you can provide extended versions of structs. This can help significantly simplify interpreting your data and prevent copying.