4

I would like to give my object a unique ID (to be able to compare them). I figured to do something along these lines:

pub struct Player {
    id: i32,
    score: usize,
}

impl Player {
    fn new() -> Player {
        let mut player = Player {};
        player.id = &player as *const i32;
        player
    }
}

I run into the problem that I need to set the variables when defining the Player, but there is no memory address at that point.

I could make the id mutable, but there is no need to change the variable after initialisation.

How can I do something like this?

EJoshuaS - Stand with Ukraine
  • 11,977
  • 56
  • 49
  • 78
Patrick
  • 303
  • 4
  • 13
  • 2
    *to be able to compare them* — **why** do you think you need this? Why not use value-based equality? Literally writing `#[derive(PartialEq)]` before the `struct` will allow you to compare two instances for equality. – Shepmaster Feb 12 '19 at 21:31
  • *I could make the `id` mutable* — you cannot make fields mutable. Mutability is a property of the variable binding, not the type. *there is no need to change the variable after initialisation* — that's extremely suspicious, considering that the memory address of the variable can change every time you move it, starting with when you return it from your constructor. – Shepmaster Feb 12 '19 at 21:34
  • 2
    I believe your question is answered by the answers of [Generate sequential IDs for each instance of a struct](https://stackoverflow.com/q/32935808/155423). If you disagree, please **[edit]** your question to explain the differences. Otherwise, we can mark this question as already answered. – Shepmaster Feb 12 '19 at 21:36
  • 5
    That being said, I think you are suffering from a strong case of [the X-Y problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). – Shepmaster Feb 12 '19 at 21:36
  • If you are deadset on using the memory address (with the knowledge that values can move in memory), then see [Are unique object ids tracked and can we print them?](https://stackoverflow.com/q/30157258/155423); [Is there a way to distingush between different `Rc`s of the same value?](https://stackoverflow.com/q/37706596/155423); [How to check if two variables point to the same object in memory?](https://stackoverflow.com/q/39463760/155423) – Shepmaster Feb 12 '19 at 21:45
  • 1
    If what you want is reference equality, the Q I flagged is your duplicate. But if you're going for motonically increasing IDs, mcarton's is a closer match. What isn't clear is what happens when a value is moved: should its ID change or not? – trent Feb 12 '19 at 22:05
  • Your idea cannot work. [The stack address of the temporary players in `new` will always be the same, and thus they will all have the same id.](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e6f2877de1b6e0e0c3aa2056b277b05d) – mcarton Feb 12 '19 at 22:10
  • [Inlining works](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2b74478624dcbc25fd5a9147ff50efbb), until [it doesn't](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3889fcee2b2412bfdcfb8778a2edf1ca). – mcarton Feb 12 '19 at 22:13
  • @mcarton Not sure if that was partially directed at me or not; to be clear, if all you need is reference equality, you would not store an `id` in the object because all you need is a reference to it. – trent Feb 12 '19 at 22:27
  • It wasn't directed at you, but at the OP. – mcarton Feb 12 '19 at 22:35
  • @mcarton It will not *always* be the same. It will depend on where you are in the stack. For example [this here essentially makes the id depend on the number of stack frames of function `p`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a3198e416a9cb419d83e56605a47605d)... which is just as useless. – Andrey Tyukin Feb 12 '19 at 22:58
  • Yes, as long as it is *sometimes* the same, this method is useless. – mcarton Feb 12 '19 at 23:03
  • @trentcl It was indeed the duplicate you flagged. I needed to know if two references point to the same struct. Thanks for the pointer! I was searching using the wrong keywords en thus did not find that question. – Patrick Feb 14 '19 at 08:06
  • No problem! That's what duplicates are for -- connecting lots of questions that all relate to the same answer but use different keywords to describe it. – trent Feb 14 '19 at 12:54

0 Answers0