[Breaking change] Reduce or eliminate the use of raw pointers about paho.mqtt.cpp

[jadamcrain]

I was about to open the same ticket related to the API callbacks.

user_callback cb;
client.set_callback(cb);

sample_mem_persistence persist;
mqtt::client client(SERVER_ADDRESS, CLIENT_ID, &persist);

Also, all of the subscription listeners...

Real-world applications have configurable subscriptions via configuration. There's no way to do this with static allocation on the call stack. I'm finding that I have to keep a std::vector<std::unique_ptr<>> of my dynamic subscriptions around, and then hand the raw pointers to client. This is less than ideal, when we really want the client to take ownership of the callbacks.

My recommendation would be to make all of these callbacks be std::shared_ptr. The overhead if minimal, but it gives the user maximum flexibility in how they manage the lifetimes of things.

[fpagliughi]

Yes, I agree with you. I originally wrote the library early in my C++11 experience, and though I was long familiar with smart pointers, I still resisted their use in a number of circumstances, like with callback objects. And I really didn't grasp the power of move semantics at the time.

After doing the Rust client library last year, I evolved my view of memory safety and ownership. Rust defaults to move semantics for function parameters, which is very interesting.

I would most likely use move operations to transfer ownership of callback and persistence objects into the client. Can you think of a reason to share ownership with any place outside of the client? I would assume that we could provide getter's that return const references if anyone wanted to refer to them.

As for the subscription listeners, yeah I hadn't thought of that. My real-world applications have mostly been small, deeply embedded apps that have static subscription requirements.

For the near future we're stuck with the current API as far as breaking changes go. But there's a 2.0 somewhere down the road, and I think it will adapt these ideas and quite a few more from the Rust client.

I will likely have more questions about the dynamic subscriptions. Feel free to throw some more ideas in here about what you would like to see.

[jadamcrain]

thanks @fpagliughi.

I went through the exact same learning XP with my C++11 project:

https://github.com/automatak/dnp3

Using unique_ptr and moving ownership upon subscription creation would be fine. In my library I tend to use shared_ptr b/c it gives people ability to use the same handler for multiple things (equivalent of subscriptions in that library). It's not a big deal though. People can always work around things easily if they need shared behavior using a shim class.