Feat/markeremitter component - #32
Conversation
| }; | ||
|
|
||
| std::vector<Binding> bindings; | ||
| std::vector<ActiveSubscription> activeSubscriptions; |
There was a problem hiding this comment.
One decision worth talking about is storing "Binding"s and "ActiveSubscription"s separately. ActiveSubscription is a resolved binding, and I think we should think if the types shouldn't be combined, having uninitialized fields that get initialized onSceneReady. The downside of that approach is more complicated logic if any rebinding is to happen. I have chosen this one at first, as the clear separation of a POD type and more complicated resolved type easily mimics the config/runtime separation and allows for rebinding, refreshes etc. later
|
|
||
| MarkerEmitterComponent::~MarkerEmitterComponent() { | ||
| for (auto& sub : activeSubscriptions) { | ||
| sub.delegate->unsubscribe(sub.link.get()); |
There was a problem hiding this comment.
Note that MarkerEmitter component contains raw pointer to delegate from another component that may also be from a different object, so if that object gets destroyed before object that contains MarkerEmitter, than this line will cause heap-use-after-free. maybe we should consider making subscription bidirectional?
There was a problem hiding this comment.
add a test that reproduces real ownership, so that we know that our program shuts down without heap-use-after-free
2 participants
resolves #28