In the doc, it said:
transmuteis semantically equivalent to a bitwise move of one type into another. It copies the bits from the source value into the destination value, then forgets the original. It’s equivalent to C’smemcpyunder the hood, just liketransmute_copy.
Does it allocate memory and do memcpy?
No. The caller of transmute must already have a destination for the output to be stored in.
Only in the sense that every function call allocates memory: When you call a function, the compiler allocates some space in the caller's stack frame to hold the return value; the output of transmute is stored there, just like any other return value would be.
(NB: This is greatly simplified from the real process; small values might stay in registers and never touch memory, for example.)
Be aware that @2e71828 talks about memory on the stack, but "allocating memory" usually refers only to memory allocated on the heap.
How about str::as_bytes()? Does it alloc memory on stack?
And, no matter alloc or not, the memcpy always happens, right?
The transmute in as_bytes takes a fat pointer (&str) and returns a fat pointer (&[u8]). A fat pointer is exactly two regular pointers big, so it it was a regular call as_bytes would take it in two registers and return it in two registers. The function body would at most shuffle the registers around if necessary when optimizations are enabled. However because as_bytes is marked as #[inline(always)], it will optimize to a no-op.
No, the compiler may optimize the memcpy away and in fact likely will for small values in favor of passing it around in registers if there are free registers.
So transmute and as_bytes are zero cost?
Yes.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.