| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
Where is robot_model::RobotModelPtr or robot_state::RobotStatePtr defined? When searching through sources; I can see numerous usages of them; but I can't track down what they are and where they are defined.
Thanks
As discussed on the MoveIt Discord: They are just pointers to RobotModel and RobotState* (see robot_model.h and robot_state.h respectively). All the xxxPtr, xxxConstPtr etc. pointers are defined via MOVEIT_CLASS_FORWARD at the start of those header files. See class_forward.h and declare_ptr.h for the definition of that macro:
#define MOVEIT_DECLARE_PTR_MEMBER(Type)
typedef std::shared_ptr<Type> Ptr;
typedef std::shared_ptr<const Type> ConstPtr;
typedef std::weak_ptr<Type> WeakPtr;
typedef std::weak_ptr<const Type> ConstWeakPtr;
typedef std::unique_ptr<Type> UniquePtr;
typedef std::unique_ptr<const Type> ConstUniquePtr;
So not only RobotModelPtr, but also RobotModelConstPtr, RobotModelWeakPtr etc. are defined, but there is no explicit definition your IDE displays, and you won't find them with simple Ctrl+F.
I found this confusing as well, and it's not easy to figure out if you don't know the pattern. I'm not sure how to make it easier to discover when you read the code, but feel free to submit a PR with documentation.
Any self-respecting editor designed for writing code should be able to tab-complete shared_ptr<>. Even vim does this for me. I also found this confusing and sad when I discovered that shared_ptr is the default pointer type and not unique_ptr or something that doesn't make reasoning about lifetime and therefore invariance really hard. You wouldn't make everything a friend class and throw out the ability to reason about private state, so why do we make everything a shared_ptr and throw out the ability to reason about lifetime?
Tyler: I won't argue with you about the "shared_ptr should not be used like this" aspect. I fully agree.
But that's not what this was about.
Please don't conflate different issues.
Macros are a standard part of C and C++, and editors do have support for those.
I'm not dismissing the frustration reported by the OP, or yours. I just wanted to let (future) readers know that there is tooling which will make your life as a C++ programmer much easier. No need to "text search" for type definitions.
"Macros are a standard part of C and C++" (only because deprecating part of C is not something C++ has been willing to do yet). If they'd get rid of macros and operator[] c++ would be a much better language imho. This has really devolved, I would just like anyone who finds this to try to avoid using Ptr if they can help themselves.
Asked: 2020-09-14 07:29:08 -0500
Seen: 233 times
Last updated: Sep 14 '20
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
