how to receive non-const shared_ptr without copies when publishing between nodelets? [closed]
I have several nodelets sharing a C++ class adapted to ROS message_traits. I'm publishing a non-const shared_ptr to other nodelets. The nodelets expecting a ConstPtr on the callback receive the same data (the .get() method of the shared_ptr returns the same number from sender to receivers). However, on another I'm receiving a non-const shared_ptr as well and in this case a copy of the object is made (I can confirm this several ways, .get() also returns a different number).
I understand that problems could arise if an object is modified on the receiver and the sender does not expect this, but I hoped this would be a decision left to the user and not enforced by performing a copy in this case. Since I publish a non-const object, I expect to be able to receive a non-const object without any intermediate copies. My code ensures that modifying things on the sender will not break things on receiver in this case.
Is it possible to avoid the copy?
UPDATE: I've looked a bit more into the issue and I'm starting to believe there is a bug.
The matter occurs when publishing a non-const shared_ptr and I have one non-const subscriber AND another subscriber (be it const or non-const). If I have a single non-const, two non-const or one const subscriber, it works. However, having one non-const with any others trigger the problem. Note that it appears the non-const subscribers receive the copy and this only happens after a second sending of the message. It all leads me to believe that, whenever a non-const subscriber's callback is called, for some reason, an internal const version of the message is stored somewhere in the ROS pipeline. Afterwards, any other invoked non-const callback sees that since it has an internal const ptr stored, it needs to perform a copy to offer the non-const version. However, it appears as a contradiction since I can at least once receive the non-const version so it appears the behavior is unintended.
