the future of ompl::base::State

[ompl]

the future of ompl::base::State

[mamoll]

Original comment by gipson_b (Bitbucket: gipson_b, ).

---

(Reply via [email protected]):

I'll give a strong second to this, a state is meaningless without context, and it's often the case that a StateSpace is required when working with States.
For example when distance computations are required.

[mamoll]

Original comment by Mark Moll (Bitbucket: mamoll, GitHub: mamoll).

---

Having a StateSpace pointer in every state would eliminate the need for ScopedState. However, the justification for not having this pointer that in any context where you accessing states you also have access to the state space, directly or indirectly (via SpaceInformation or SimpleSetup). Your math for memory usage is not quite right. If I have a compound state space with n copies of SO(2), the memory usage would double. If I start nesting compound state spaces, it gets even worse. IMO, more raw pointers will lead to more bugs. It's hard to guarantee that a state contains a pointer to the right state space (not just the right type, but the right instance). The semantics of who is responsible for allocation/deletion of states could get a little fuzzy. As you can tell, I am not so keen on it.

[mamoll]

Original comment by Ryan Luna (Bitbucket: rluna, GitHub: rluna).

---

I'm not necessarily against adding the member pointer, but I'm not sure it is actually useful and the change may introduce more problems than it fixes.

Nearly every component has access to the StateSpace via SpaceInformation, and all of the general state operations can already be accessed there. Since the raw pointer would be saved in the state object, there could be some issues if the StateSpace was destroyed but some states were still hanging on to this pointer. We are currently insulated from this by using glorified blobs for states, which are distinct from the instance of StateSpace from which they were created (ScopedState uses StateSpacePtr). Also, creating a state the "easy way" using new may actually require more code since we would still need a handle to the StateSpace to give to the newly created state.

[mamoll]

Original comment by Ioan Sucan (Bitbucket: isucan, GitHub: isucan).

---

This makes sense. We should not do it for now.

[mamoll]

Original comment by Mark Moll (Bitbucket: mamoll, GitHub: mamoll).

---

appveyor fix #6