I need this in KIO, where a (soon deprecated) method takes a KService by const
ref, but I want to implement a KJob behind the scenes, which means starting
delayed, so I need to clone that KService object. The job will take a
KService::Ptr to avoid needing this in future code.
Some context of reviewers: this is all based on QExplicitlySharedDataPointer.
Builds, new tests pass
| No Linters Available |
| No Unit Test Coverage |
| Buildable 16513 | |
| Build 16531: arc lint + arc unit |
Surprising to have QSharedData on the outside type rather than on the private class, but that isn't something this patch introduces.
Yes, this is inheritance from the old KSharedPtr.
Basically this gives the choice between using an actual shared pointer (KService::Ptr) and just using KService on the stack directly for simple cases. Just like you get with std::shared_ptr.
The big difference with shared_ptr however is that the refcount is in the pointed-object rather than in the pointer, which has the benefit that a roundtrip like Ptr -> raw pointer -> Ptr (as is done in many places) doesn't lead to crashes. This type of code was deemed too much trouble to port away from, back when we looked into strategies for porting away from KSharedPtr, which is why we kept the architecture where the refcount is part of the (public) pointed-to object.