Ask Your Question

Where is the definition of the ...Ptr naming standard

asked 2020-09-14 07:29:08 -0500

bgraysea gravatar image

updated 2020-09-14 07:43:36 -0500

fvd gravatar image

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.


edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2020-09-14 07:48:14 -0500

fvd gravatar image

updated 2020-09-14 07:48:49 -0500

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:

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.

edit flag offensive delete link more


Any self-respecting IDE should be able to take you to these definitions after clicking on them. It should even be able to expand the macro for you.

gvdhoorn gravatar image gvdhoorn  ( 2020-09-14 14:44:55 -0500 )edit

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-picknik gravatar image tyler-picknik  ( 2020-09-15 08:48:06 -0500 )edit

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.

gvdhoorn gravatar image gvdhoorn  ( 2020-09-15 08:50:34 -0500 )edit

"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.

tyler-picknik gravatar image tyler-picknik  ( 2020-09-15 09:19:17 -0500 )edit

Could all be, but fact is that right now, it's part of the language (or at least supported by the toolchain).

gvdhoorn gravatar image gvdhoorn  ( 2020-09-15 09:28:59 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-09-14 07:29:08 -0500

Seen: 127 times

Last updated: Sep 14 '20