Closed dlyr closed 2 years ago
Merging #997 (65f7607) into release-candidate (f530ebf) will decrease coverage by
0.01%
. The diff coverage is25.00%
.:exclamation: Current head 65f7607 differs from pull request most recent head 6a2680a. Consider uploading reports for the commit 6a2680a to get more accurate results
@@ Coverage Diff @@
## release-candidate #997 +/- ##
=====================================================
- Coverage 42.07% 42.06% -0.02%
=====================================================
Files 341 341
Lines 22579 22574 -5
=====================================================
- Hits 9500 9495 -5
Misses 13079 13079
Impacted Files | Coverage Δ | |
---|---|---|
src/Engine/RadiumEngine.hpp | 100.00% <ø> (ø) |
|
src/Gui/BaseApplication.cpp | 0.00% <0.00%> (ø) |
|
src/Gui/BaseApplication.hpp | 0.00% <ø> (ø) |
|
src/Headless/CLIViewer.cpp | 56.52% <100.00%> (-0.38%) |
:arrow_down: |
src/Engine/Scene/SystemDisplay.cpp | 23.07% <0.00%> (-5.50%) |
:arrow_down: |
src/Engine/Scene/ComponentMessenger.cpp | 90.90% <0.00%> (-0.76%) |
:arrow_down: |
src/Engine/RadiumEngine.cpp | 63.48% <0.00%> (-0.16%) |
:arrow_down: |
src/Gui/Utils/KeyMappingManager.cpp | 76.73% <0.00%> (-0.07%) |
:arrow_down: |
src/Engine/Rendering/DebugRender.cpp | 25.98% <0.00%> (+0.20%) |
:arrow_up: |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
@dlyr to you want to clean the history before merging ? (fine for me as it is now)
Be aware that the PR request cannot be accepted if it doesn't pass the Continuous Integration tests.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) Use unique_ptr as singleton instance
What is the current behavior? (You can also link to an open issue here) Singleton use raw ptr
What is the new behavior (if this is a feature change)? Using unique_ptr prevent from missing destroyInstance, and make clang-tidy happier.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) Maybe related to the use of awkward unique_ptr to singleton instance (which make the unique_ptr owner virtually the owner of the singleton instance and can arise spurious singleton delete).
Other information: need to be tested, maybe simply remove class member singleton views. Or use shared_ptr/weak_ptr, or reference_wrapper, as introduce here #996