Convert some ints into a byte array without allocations?

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 16, 2016 14:34:54 Samson Smith via Digitalmars-d-learn wrote:
> I'm trying to make a fast little function that'll give me a
> random looking (but deterministic) value from an x,y position on
> a grid. I'm just going to run each co-ord that I need through an
> FNV-1a hash function as an array of bytes since that seems like a
> fast and easy way to go. I'm going to need to do this a lot and
> quickly for a real time application so I don't want to waste a
> lot of cycles converting data or allocating space for an array.
>
> In a nutshell how do I cast an int into a byte array?
>
> I tried this:
>
> byte[] bytes = cast(byte[])x;
> > Error: cannot cast expression x of type int to byte[]
>
> What should I be doing instead?

For this particular case, since you're hashing rather than doing something
like putting the resulting value on the wire, the cast that others suggested
may very well be the way to go, but the typesafe way to do the conversion
would be to use std.bitmanip.

    int i = 12345;
    auto arr = nativeToBigEndian(i);

where the result is ubyte[4], because the argument was an int. If it had
been a long, it would have been ubyte[8]. So, you avoid bugs where you get
the sizes wrong. The only reason that I can think of to _not_ do this in
your case would be speed, simply because you don't care about swapping the
endianness like you would when sending the data via a socket or whatnot. Of
course, if you knew that you were always going to be on little endian
machines, you could also use nativeToLittleEndian to avoid the swap, though
that still might be slower than a simple cast depending on the optimizer (it
uses a union internally).

But it will be less error-prone to use those functions, and if you _do_
actually need to swap endianness, then they're exactly what you should be
using. We've had cases that have come up where using those functions
prevented bugs precisely because the person writing the code got the sizes
wrong (and the compiler complained, since nativeToBigEndian and friends
deal with the sizes in a typesafe manner).

- Jonathan M Davis