Qt: add automated smart pointer for CoreController #3549
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ahigerd
force-pushed
the
alh/refactor-popups-part-1
branch
2 times, most recently
from
48a992b to
4a8f20b
Compare
ahigerd
force-pushed
the
alh/refactor-popups-part-1
branch
from
4a8f20b to
46135fb
Compare
Contributor
Author
|
Next PR in the series: ahigerd#3 |
ahigerd
commented
Aug 8, 2025
Comment on lines
+583
to
+596
| namespace { | ||
| class RefAdaptor | ||
| { | ||
| public: | ||
| RefAdaptor(CorePointerSource& source) : source(&source) {} | ||
|
|
||
| inline operator CorePointerSource&() { return *source; } | ||
| inline operator CorePointerSource*() { return source; } | ||
| inline operator std::shared_ptr<CoreController>() { return *source; } | ||
|
|
||
| CorePointerSource* source; | ||
| }; | ||
| } | ||
|
|
Contributor
Author
There was a problem hiding this comment.
This is temporary and the next PR removes it. It's only here so I don't have to make all of the changes at the same time.
Contributor
Author
|
Third PR in the series: ahigerd#4 |
Contributor
Author
|
Fourth PR in the series: ahigerd#5 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first of a series of patches that intend to refactor the way mGBA handles popup windows.
Second PR: ahigerd#3
Third PR: ahigerd#4
Fourth PR: ahigerd#5
Description
CorePointeris a weak pointer to a boxed shared pointer toCoreControllerwith change callbacks. That is:CorePointerSourcemostly-transparently wraps aroundshared_ptr<CoreController>CorePointeracts as aCoreControllersmart pointer, but it returns the pointer contained by its associatedCorePointerSource.CoreConsumeris an interface type exposing attach and detach callbacks.CorePointerSourcehas a newCoreControllerassigned to it, each associatedCorePointerwill dispatch callbacks to theCoreConsumerthat owns it.CorePointerSourceis destroyed, all associatedCorePointerobjects become null pointers.Motivation
Primarily, I wanted to unify how all of the various popup dialogs that depend on
Windowto set them up get access toCoreController. This will simplify the next step of the popup refactor by allowing a single code path to handle all such view classes.Considered alternatives
My previous PR had used some arcane C++ template metaprogramming to avoid needing to introduce an interface class. I know you don't like multiple inheritance, but I think this is a lot more straightforward of an implementation that I expect to be easier to maintain going forward. If you insist, I can switch this back to a metaprogramming-based implementation. (However, it will beget even more awkward metaprogramming in the next phase because having a common base class makes it MUCH easier to detect what APIs a view supports.)
C++20 introduces some new template metaprogramming features that would make it significantly less ugly, but I don't expect you want to make that jump yet.
I could also use lambdas as delegates, with an API something along the lines of
m_controller.connectAttach(this, &FooView::onCoreAttached); m_controller.connectDetach(this, &FooView::onCoreDetached);. This wouldn't change the implementation very much but it would increase the boilerplate on every class that uses it. (And I would still need the additional metaprogramming in the next phase.)