-
Notifications
You must be signed in to change notification settings - Fork 14
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
ScopedCFRef helper to manage CF objects #36
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #36 +/- ##
==========================================
+ Coverage 48.51% 50.26% +1.75%
==========================================
Files 3 3
Lines 202 187 -15
Branches 77 76 -1
==========================================
- Hits 98 94 -4
+ Misses 45 30 -15
- Partials 59 63 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
I mainly looked at the ScopedCFRef<>
. Not so much its usage. I'm not super familiar with the Apple APIs, unfortunately. Nevertheless, one word of warning: If some API takes ownership of a CFRef
you're passing in, you might want to have something like:
T release() {
auto out = _ref;
_ref = nullptr;
return out;
}
Otherwise, macOS might free something internally that your ScopedCFRef<>
freed already.
Particularly createQuery()
could be prone to that, as it creates a CFMutableDictionaryRef
that is appended with some objects that are auto-released in the same scope. The CFMutableDictionaryRef
is eventually returned and therefore lives longer than its members. Maybe CFDictionaryAddValue()
creates a deep copy, though, no idea. Just putting this out here.
Add a ScopedCFRef wrapper for CF objects that ensures that CFRelease is called when it leaves the scope.