-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add semantics to move a blob. #154
Conversation
78b5807
to
4da802f
Compare
Codecov Report
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. @@ Coverage Diff @@
## master #154 +/- ##
==========================================
- Coverage 64.02% 63.49% -0.54%
==========================================
Files 71 71
Lines 4306 4303 -3
Branches 530 529 -1
==========================================
- Hits 2757 2732 -25
- Misses 1323 1343 +20
- Partials 226 228 +2
|
|
||
blob() : blob{nullptr, 0} {} | ||
blob(uint8_t* const b, const uint32_t s) : bytes{b}, size{s} {} | ||
std::byte* bytes{nullptr}; |
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.
There are several places that are using blob as uint8_t*. Shouldn't this be a major version upgrade?
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.
probably, though are we using master
with the sisl::blob
anywhere? I don't think OM uses it and 1.3 AM is still on stable right? But you're right, a 10.x
is warranted.
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.
Yeah, we are only using it in the 2.0 data side of things.
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.
lgtm! I will wait for @hkadayam 's review before approving.
One use case of the shared-ptr of byte-arrray in HomeStore is component-A passes the shared point of byte-array to Component-B, and B read that memory (for write to disk), and then B finishes the API (it is a sync-call) and return to A and A still owns that byte-array as A will periodically update that same memory and pass it to B by calling that API. |
We don't need to wrap a byte_array_impl (or other blob) in a shared_ptr/unique_ptr if we have move semantics since the underlying is just a pointer mostly anyways as well. The user-defined destructor will handle RAII, no need for a pointer to a pointer I think?
We can enforce ownership via the API signature, (e.g.
void put(Blob&& blob, ...
forcing the user to release ownership and making for cleaner code with less de-referencing and checking fornullptr
.