• 1 Post
  • 15 Comments
Joined 1 year ago
cake
Cake day: July 5th, 2023

help-circle
  • Ah I didn’t realize most people have moved onto OnceCell. The issue with both lazy static and oncecell is that they can only be assigned to once. You need a global mutable state, so neither OnceCell or lazy_static are the right choice.

    You’re going to be fighting the borrow checker if you try to have global mutable state. It will bite you eventually. You can potentially use an interior mutablity pattern along with a mutex. Have you looked into interior mutability?





  • Ideally, all of these values should be represented in memory exactly the same way:

    That would make the game hard to play, since you’d have to think about where your move would end up since it won’t stay on the cell you click.

    I think you’re wanting to store them that way so that you can easily check for win conditions, maybe? But that’s the wrong approach. Store the cells as they appear to the player, in a 2d Array (or 1d Array with indexing math. That’s how I’d do it).

    Then you can take advantage of symmetries in your win condition code, if you like. But it really couldn’t be much simpler than counting the matching cells in each row, column, and diagonal. That’s just 8 groups of 3.


  • Oh I see. I misunderstood the reason for wanting it represented as an int.

    I’m wondering if you could just create a wrapper type that only has an int as a member, but then implement a trait on it so that it can act like a result. That, or just pass around your int type in the rust code, and when you need it to act like a result you do a conversion from int to result. Your debugger wouldn’t show it as an int at that point, but it wouldn’t show any other Result as an int anyway so it would br consistent with other rust code. If this still doesn’t work, you could even make a struct that contains both the int and the result and keeps then synchronized. Then, when debugging, you could look into that struct and see the int value like you want.




  • Well if you want to keep an int as an int, then use an int. If you want to use Results, use results. Like I said to the other commenter: unless this code is in a very tight loop where performance is crucial, you’ll be fine just implementing From/Into to change your Result to and from an int. You’re already crossing a language boundary by calling c code from Rust. Is it that much more of an issue to just convert the types when you need to?

    Trying to store the results as an int in some magical way just screams premature optimization. You have abstraction tools at your disposal. They may not be zero cost, but they are cheap. Use them.