Comments (3)
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.
from paho.mqtt.cpp.
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.
from paho.mqtt.cpp.
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.
from paho.mqtt.cpp.
Related Issues (20)
- No consumer notification when broker cleanly disconnects HOT 3
- paho.mqtt.cpp looks for PahoMqttC, but the package named - eclipse-paho-mqtt-c. HOT 2
- CMake Error when PAHO_BUILD_SAMPLES=TRUE (Cannot find src/samples/async_consume_v5.cpp) HOT 1
- Why is this project under Eclipse v1.0 when paho.mqtt.c is under Eclipse v2.0? HOT 1
- Building paho.mqtt.cpp: cmake doesn't pick up my c++ compiler correctly. HOT 4
- Homebrew Installation HOT 1
- Automatic Reconnect Crashes MQTT when `client.reconnect()` is called HOT 7
- Connect failed, more to try HOT 1
- SSL_read() Segmentation fault
- Build with PAHO_WITH_MQTT_C is broken HOT 3
- broker(emqx) already support QUIC, and i Hope client also supports the Quic protocol HOT 1
- arm cross get error HOT 5
- Add getter for the connect_options object (connOpts_) in async_client
- Operation not permitted on try_consume_message async HOT 1
- Base64TestOpenSSL giving problem and how to use only paho-mqtt3as libraray project in visual studio HOT 1
- Cross compilation of paho.mqtt.cpp HOT 9
- cmake issue in Docker container HOT 2
- error in install_paho_mqtt_c.sh in the installation process of the latest version of paho.mqtt.cpp HOT 1
- ThreadSanitizer: lock-order-inversion (potential deadlock) paho 1.2.0
- Linker-Error when compiling with v1.3.2 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from paho.mqtt.cpp.