Ancestors

Toot

Written by yugaego 🌍 on 2024-09-14 at 08:03

[#]rustlang memory management again.

Finally nailed it 😂

Time to copy/paste the URL of the page on Object Copying.

https://en.wikipedia.org/wiki/Object_copying

=> More informations about this toot | More toots from yugaego@fosstodon.org

Descendants

Written by d2718 on 2024-09-15 at 01:04

@yugaego Hello, fellow Crab person!

The #rustlang tag brought this across my feed. I am not a huge fan of being That Guy, but this seems not quite correct to me (but I could also just be misunderstanding you). Anyway, it got me thinking, and writing a response seemed like a good way to make sure I felt like I was thinking about it correctly. Mastodon's character limit rapidly made that impractical, so I ended up writing a blog post.

https://d2718.net/blog/posts/copy_clone_move.html

=> More informations about this toot | More toots from d2718@hachyderm.io

Written by d2718 on 2024-09-15 at 01:05

@yugaego

I hope it helps! (Writing it has already helped me.)

=> More informations about this toot | More toots from d2718@hachyderm.io

Written by yugaego 🌍 on 2024-09-15 at 06:34

@d2718 The quotes that sparked a conceptual joke:

"Assigning a value of a Copy type copies the value, rather than moving it. The source of the assignment remains initialized”

“In Rust, every move is a byte-for-byte, shallow copy that leaves the source uninitialized. ”

“Potentially expensive operations should be explicit, like the calls to clone in the earlier example that make deep copies of vectors and the strings they contain.”

https://www.oreilly.com/library/view/programming-rust-2nd/9781492052586/

=> More informations about this toot | More toots from yugaego@fosstodon.org

Written by d2718 on 2024-09-15 at 22:18

@yugaego Oh, wow, okay; I didn't see this! How embarrassing. I guess I get it now, although it'd be funnier if this weren't a published O'Reilly book people are evidently trying to learn from. I don't mind that third statement, but the first two make my eyes water. 😵‍💫

=> More informations about this toot | More toots from d2718@hachyderm.io

Written by yugaego 🌍 on 2024-09-16 at 09:58

@d2718 But they haven't written anything wrong. I'm surprised you could think so of such a prominent Rust book.

In short, both 'copy' and 'move' are performed with memcpy(), which copies a block of memory from source to destination (bitwise, shallow copy).

In a case of 'move', this often gets optimized by compiler to not copying values. But optimizations are never guaranteed, in opposite to memcpy() calls.

P.S. I still find it unethical partially quoting someone without linking to source.

=> More informations about this toot | More toots from yugaego@fosstodon.org

Written by d2718 on 2024-09-16 at 17:47

@yugaego Except every move (or Copy-type assignment) isn't necessarily a copy! And "initialized"/"uninitialized" are lousy terms to use here; after a move, the source binding is certainly invalid (and the compiler rightly goes out of her way to prohibit its use), but those bytes aren't "uninitialized" (especially if the copy has been optimized away--although I wouldn't even call that an optimization so much as the semantics of the language).

=> More informations about this toot | More toots from d2718@hachyderm.io

Written by dorotaC on 2024-09-25 at 17:14

@d2718 @yugaego When would a move not be a copy?

As far as I know, this is true except for zero-sized types.

=> More informations about this toot | More toots from dcz@fosstodon.org

Proxy Information
Original URL
gemini://mastogem.picasoft.net/thread/113134861592833578
Status Code
Success (20)
Meta
text/gemini
Capsule Response Time
1560.876334 milliseconds
Gemini-to-HTML Time
1.151387 milliseconds

This content has been proxied by September (3851b).