-
Notifications
You must be signed in to change notification settings - Fork 8
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.
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
Dereg individual #226
Dereg individual #226
Conversation
…d pointers because UwbConnector needs to be able to know whether the individual callbacks are stale
An explicit type for each callback seems fine to me since there are actually different callback prototypes, so we really can't avoid them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really well done. I added some comments with suggestions for consolidating stuff and simplifying the callback instances themselves, but otherwise this looks great.
I just ran a regression test on the basic ranging scenario, and it passes. So it should be ready for merging now |
Type
Goals
Allow the deregistration of individual callbacks.
Technical Details
Since some callback function signatures are ambiguous, I decided to make separate types for each callback. These types are used internally by UwbConnector to keep track of what's what.
On the client side (i.e. UwbDevice and UwbSession), things largely stayed the same. They still fill out the structure of device callbacks or session callbacks, which they pass into Register[Device|Session]EventCallbacks. However, now those functions return a structure containing weak_ptr to the callback tokens corresponding to each of the callbacks they registered. If the client leaves some callbacks out of the structure, then the callback token for those callbacks will be nullptr (and the UwbConnector won't have added that token to its internal storage). The structure containing all session or device callbacks is nice to have in the interface because it allows the client to unambiguously label the callbacks as what they are, without needing to be aware of all the internal types UwbConnector uses to keep track.
Test Results
Regression tests pass
Reviewer Focus
Are there any other approaches to this that avoid the problem of having to define a type for each callback?
Future Work
Checklist
all
compiles cleanly.