Skip to content

Clarify publish behavior for shared_ptr and unique_ptr #344

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Yuchen966 wants to merge 2 commits into
base: gh-pages
Choose a base branch
from
Open

Clarify publish behavior for shared_ptr and unique_ptr #344

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f5a8ba1
Clarify publish behavior for shared_ptr and unique_ptr
Oct 20, 2025
d7e22ca
emphasize constness of messages in shared_ptr of IPC behaviour
Nov 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 7 additions & 19 deletions articles/intraprocess_communication.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -329,7 +329,7 @@ If all the `Subscription`s want ownership of the message, then a total of `N-1`
The last one will receive ownership of the published message, thus saving a copy.

If none of the `Subscription`s want ownership of the message, `0` copies are required.
It is possible to convert the message into a `std::shared_ptr<MessageT> msg` and to add it to every buffer.
It is possible to convert the message into a `std::shared_ptr<const MessageT> msg` and to add it to every buffer.

If there is 1 `Subscription` that does not want ownership while the others want it, the situation is equivalent to the case of everyone requesting ownership:`N-1` copies of the message are required.
As before the last `Subscription` will receive ownership.
Expand All @@ -351,29 +351,17 @@ The notation `@` indicates a memory address where the message is stored, differe
| ----------------------- | ----------------------- | ----------------------- |
| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> | @1 |
| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> unique_ptr\<MsgT\> | @1 <br> @2 |
| unique_ptr\<MsgT\> @1 | shared_ptr\<MsgT\> | @1 |
| unique_ptr\<MsgT\> @1 | shared_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @1 <br> @1 |
| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @1 <br> @2 |
| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> shared_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @1 <br> @2 <br> @2|
Copy link
Contributor

@alsora alsora Nov 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think these should be removed

| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> unique_ptr\<MsgT\> <br> shared_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @1 <br> @2 <br> @3 <br> @3|

#### Publishing SharedPtr

| publish\<T\> | BufferT | Results |
| ----------------------- | ----------------------- | ----------------------- |
| shared_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> | @2 |
| shared_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> unique_ptr\<MsgT\> | @2 <br> @3 |
| shared_ptr\<MsgT\> @1 | shared_ptr\<MsgT\> | @1 |
| shared_ptr\<MsgT\> @1 | shared_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @1 <br> @1 |
| shared_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @2 <br> @1 |
| shared_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> shared_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @2 <br> @1 <br> @1|
| shared_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> unique_ptr\<MsgT\> <br> shared_ptr\<MsgT\> <br> shared_ptr\<MsgT\> | @2 <br> @3 <br> @1 <br> @1|
| unique_ptr\<MsgT\> @1 | shared_ptr\<const MsgT\> | @1 |
| unique_ptr\<MsgT\> @1 | shared_ptr\<const MsgT\> <br> shared_ptr\<const MsgT\> | @1 <br> @1 |
| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> shared_ptr\<const MsgT\> | @1 <br> @2 |
| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> shared_ptr\<const MsgT\> <br> shared_ptr\<const MsgT\> | @1 <br> @2 <br> @2|
| unique_ptr\<MsgT\> @1 | unique_ptr\<MsgT\> <br> unique_ptr\<MsgT\> <br> shared_ptr\<const MsgT\> <br> shared_ptr\<const MsgT\> | @1 <br> @2 <br> @3 <br> @3|

The possibility of setting the data-type stored in each buffer becomes helpful when dealing with more particular scenarios.

Considering a scenario with N `Subscription`s all taking a unique pointer.
If the `Subscription`s don't actually take the message (e.g. they are busy and the message is being overwritten due to QoS settings) the default buffer type (`unique_ptr` since the callbacks require ownership) would result in the copy taking place anyway.
By setting the buffer type to `shared_ptr`, no copies are needed when the `Publisher` pushes messages into the buffers.
By setting the buffer type to `shared_ptr<const MsgT>`, no copies are needed when the `Publisher` pushes messages into the buffers.
Eventually, the `Subscription`s will copy the data only when they are ready to process it.

On the other hand, if the published data are very small, it can be advantageous to do not use C++ smart pointers, but to directly store the data into the buffers.
Expand Down