-1

I'm trying to hold a vector of references across the nested hierarchy (cloning is not an option), but I'm having trouble grasping lifetimes.

I've tried to summarize my code here:

struct A {
    b: B,
    c: C,
}

impl A {
    fn add(&mut self) {
        for i in self.b.d.iter() {
            self.c.e.push(&i);
        }
    }
}

struct B {
    d: Vec<E>,
}

struct C {
    e: Vec<&E>,
}

struct E {}

I'm running a simulation and storing individual results in B, and then picking up only a subset of that for visualization, so the Vec in C is compiled, rendered and discarded each frame.

My actual hierarchy is more complex than this, but I hope that if I understand this problem I'll be able to scale it up.

How do I approach setting up lifetimes here? Is this even an idiomatic Rust way or should I re-organize my entities?

Peter Hall
  • 53,120
  • 14
  • 139
  • 204
Steingrímur
  • 3
  • 1
  • 2
    Your question is very broad. You didn't say what problems you are running into. [You _cannot_ hold references to other members of the same struct](https://stackoverflow.com/questions/32300132/why-cant-i-store-a-value-and-a-reference-to-that-value-in-the-same-struct), but you didn't give any background on what you are _really_ trying to do, so it's hard to offer an alternative solution. – Peter Hall Nov 13 '19 at 12:50
  • I doubt that the architecture tag is appropriate for this question. Also, if a struct holds reference members, you need to specify references. Have you read through [the according section in the Rust Book](https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html)? – Sty Nov 13 '19 at 12:53
  • You could be looking for [Why is Vec<&str> missing lifetime specifier here?](https://stackoverflow.com/questions/57266481/why-is-vecstr-missing-lifetime-specifier-here) Does that answer your question? If so, we can mark it, but if not, I don't think it's answerable. There's nothing *wrong* with the architecture you have described, though. If you have code that works but you're not sure it's the best solution, consider asking on [Code Review](https://codereview.stackexchange.com/) instead (read the rules there first; the expectations are different). – trent Nov 13 '19 at 17:55
  • I'm sorry for being broad, I was trying to produce a minimal illustration of my problem while not sounding like I'm trying to bite more than I can chew, which obviously I am. Problem I'm facing is adding references to the Vec is causing the compiler to complain about lifetimes which I get - I am not guaranteeing objects will still be there when reference is consumed. Since this is happening across multiple structs, I am really lost at how to set up those guarantees, but I guess I still have a lot to learn. Thank you everyone for help, I really appreciate it! – Steingrímur Nov 15 '19 at 11:14

1 Answers1

-1

so the Vec in C is compiled, rendered and discarded each frame

If you only ever need to use instances of your struct C temporarily, then there is not much use in storing them as part of a struct A.

Instead, I would suggest adding a get_c function to A's impl that just generates a C on the fly (or, alternatively, go entirely without and have that function simply return a Vec<&E>)

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
Sty
  • 760
  • 1
  • 9
  • 30
  • I guess this doesn't answer the question directly, but it is a direction I went into to solve (evade) the original problem so I am accepting it as an answer. – Steingrímur Nov 15 '19 at 11:20