Update cesium-native, don't derive CesiumImpl from ReferenceCountedThreadSafe #547
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.
The only change here is to
CesiumImpl
, necessitated by a change toReferenceCounted
.CesiumGS/cesium-native#1048 slightly changed how we do CRTP in
ReferenceCounted
. See a bit of discussion about it here:CesiumGS/cesium-native#1048 (comment)
This is a good change, but unfortunately it breaks the way we were using it in Unity. In Unity, before this PR, we were deriving
CesiumImpl
fromReferenceCountedThreadSafe
, like this:So essentially
CesiumImpl
is a CRTP class itself. It's essential thatTDerived
be given as the template parameter toReferenceCountedThreadSafe
because, when the reference count goes to zero,ReferenceCountedThreadSafe
static casts to that type before deleting it. The destructor is not virtual (by design) so we must cast to the fully-derived type in order to properly delete the object.Unfortunately, this doesn't work after CesiumGS/cesium-native#1048.
CesiumImpl
isn't allowed to call the private constructor inReferenceCountedThreadSafe
because it is not a friend; onlyTDerived
is. We get compiler errors because theReferenceCountedThreadSafe
constructor is not accessible.I went around in circles a bit on how to solve this. We could go back to the old CRTP approach with a protected (instead of private) constructor, and disable the clang-tidy check that got us here. Perhaps us a static_assert to achieve something close to the safety that the private constructor / friend approach was getting us (but I can't see how to get all the way there). We could add another template parameter to
ReferenceCountedThreadSafe
, so that separate classes can be specified as the "derived" and the "friend". But then couldn't that be used to subvert the safety that the private constructor is meant to provide?In the end, I decided to leave cesium-native alone and change
CesiumImpl
to no longer derive fromReferenceCountedThreadSafe
. This is a somewhat unusual case, so I guess it's worth a bit of duplication to get what we need here, plus the safety of the private constructor in more common scenarios.