Revision history [back]

At a high level there's two patterns that we want to support. Read only access and read+write access. If you want Read Only use a ConstSharedPtr, if you want to be able to modify the message use the UniquePtr to subscribe.

We could extend the API to cover more permutations, but keeping it simple will make users code more homogeneous and consequently more standardized which will make it both more readable and easier to audit.

This will also facilitate sharing of code if everything standardizes on using these two variations of the datatypes.

Specifically looking at the permutations you suggestion.

create_subscription<std_msgs::msg::string>( "/foo", 5, this // doesn't seem to work

This makes the shared pointer itself const, and you're getting it by value such that you'd be getting a copy and it consequently wouldn't be reference counted correctly.

create_subscription<std_msgs::msg::string>( "/foo", 5, this // doesn't work either

Keeping a reference to a shared pointer doesn't make much sense, you should have your own reference counted handle to the shared pointer so that it's known that you're using the contents and that you don't have to rely on someone else persisting the lifetime of the shared pointer.

create_subscription<std_msgs::msg::string>( "/foo", 5, this // neither does this

You don't want to ask for a UniquePtr that's const. The reason to require a UniquePtr is so that you can know that you have full ownership of the message datatype to allow you to modify it. Under the hood if two subscribers request a UniquePtr datatype the subscription is required to make a copy of the message to give both subscribers unique pointers. If you just want const access to the message you should use the ConstSharedPtr and not force the subscriber to copy the data to give you a const instance if there might be other const subscribers.