Repository navigation
Conversation
88535ba to
86e7c40
Compare
|
Is it possible to recover the original concrete resource type from a ResourceRef? I'm just wondering if I'd be able to somehow get the underlying hip stream, for example. |
|
Yes, use |
|
Does the cost of the std::shared_ptr actually outweigh the cost of indirect dispatch? |
The new implementation does very similar indirect dispatch, by making its own vtable manually instead of implicitly via virtual methods, so that part is similar. I was mainly thinking of what the costs would be of adding a resource argument to the plugin interface and was interested in avoiding the allocations and atomic operations that would be required when converting a concrete resource to an erased resource. |
Add ResourceRef and EventRef classes that allow a non-const view of a resource. Also ResourceConstRef and EventConstRef for const a view. Refactor Resouce/Event to use the ref class for their implementation as much as possible. Note that to avoid allocations the Ref classes have an explicit vtable. That is needed as concrete resources have no base class.
|
If you're not changing existing Camp resource behavior, I don't understand why existing Camp resource documentation has to be removed/shortened. I would strongly urge only documentation additions - even if it seems like you're replacing something obvious, because it may not be that obvious to a new developer or user |
I'm working on changes to the branch that preserve the original documentation. |
Add ConcreteResourceAPI, ConcreteEventAPI, and Hashable concepts. Use them instead of static asserts in the vtable implementation. Use static asserts in after the concrete resources and events to ensure they are valid.
Also fix some minor things like moving a by-value arg into storage and making get_resource be the right amount of noexcept.
86e7c40 to
f4d4bd5
Compare
Instead of also having both cons and non-const ref verions
This ultimately simplifies things a bit to a version of wait_for for the native event of the resource, other concrete events, and generic events.
Do not merge until the current release has stabilized. This is a large ABI breaking change to the Resource and Event classes.
Add Ref classes for Resource and Event as a cheap type erased way to view resources or events.
The Ref class holds a type erased pointer to the concrete resource/event and a vtable pointer. This allows them to avoid using a shared_ptr and avoid making allocations. The owning Resource/Event classes still have a shared_ptr to manage ownership of their resource/event. They now inherit from Ref privately to implement the API with using statements where possible and method wrappers where there are constness differences.
The existing Resource and Event implementation uses a shared_ptr with an internal class hierarchy. This requires allocations and atomic operations. The ref implementation uses an explicit vtable instantiated for each concrete resource/event class instead of a derived class template. The code for the explicit vtable implementation takes the wrapper methods from derived class template that was instantiated for each concrete resource/event class and makes those free function pointers with an explicit type erased this pointer argument. So the main difference is having to explicitly use the vtable vs using methods through a base class pointer.