Comment
Benjamin (admin) wrote on 05 January 2025
I believe you misunderstood the blog post. The point is precisely that if I were using a language like C++, I would have opted for the solution that uses nested loops, which would have resulted in unfair gameplay when players try to land fatal blows on each other in the exact same frame.
To address the 'minor performance penalty': the vector can be allocated once and then reused. Since the maximum number of players is low (8-12), a fixed-size array on the stack could be used, making the solution fully allocation-free. I didn't mention this because it's an irrelevant implementation detail and I wanted to keep the examples as simple as possible.
reply
I believe you misunderstood the blog post. The point is precisely that if I were using a language like C++, I would have opted for the solution that uses nested loops, which would have resulted in unfair gameplay when players try to land fatal blows on each other in the exact same frame.
To address the 'minor performance penalty': the vector can be allocated once and then reused. Since the maximum number of players is low (8-12), a fixed-size array on the stack could be used, making the solution fully allocation-free. I didn't mention this because it's an irrelevant implementation detail and I wanted to keep the examples as simple as possible.
reply
Post comment
Replies
Empty_String wrote on 15 January 2025
tbf, had you used indices from the very beginning - you'd hit the logic bug in Rust as well
and had you used iterators in C++, you would not hit any memory problems that borrow checker false-alarms you about
what you actually demonstrated is that borrow checker _made you change program behaviour_ and you didn't even notice it
"removal" of logic bug could have easily been "adding" of such - and kinda points to developer experience still being important, no matter what borrow checker cult might suggest
reply
tbf, had you used indices from the very beginning - you'd hit the logic bug in Rust as well
and had you used iterators in C++, you would not hit any memory problems that borrow checker false-alarms you about
what you actually demonstrated is that borrow checker _made you change program behaviour_ and you didn't even notice it
"removal" of logic bug could have easily been "adding" of such - and kinda points to developer experience still being important, no matter what borrow checker cult might suggest
reply