Description of the feature, modification, idea, or suggestion.
The experimental UniquePtr was reverted.
The destructible pointer was intended to be in service of the unique pointer but the unique pointer implementation ended up being more or less a copy and paste of the SharedPtr. This is due to the allocator principals of the library and how UniquePtr elided the allocator type from the container while retaining polymorphic support. The normal standard gets around this by virtue of new and delete. This was more or less "fine" but carried with it the cost of two pointers in the UniquePtr implementation. Overall Radiant needs to re-approach the UniquePtr implementation.
Radiant should have an appropriate UniquePtr or suitable alternative.
The UniquePtr implementation should ideally restrict itself in size to the size of one pointer. A challenging aspect is removing the allocator from the template and supporting polymorphism. Radiant should not rely on new/delete as other libraries do. It is known that the (at least for MSVC) delete causes the return register to contain the final pointer that needs to be freed after destruction. The original approach hoped to solve this with DestrPtr but that did not prove useful.
Description of the feature, modification, idea, or suggestion.
The experimental
UniquePtrwas reverted.Radiant should have an appropriate
UniquePtror suitable alternative.The
UniquePtrimplementation should ideally restrict itself in size to the size of one pointer. A challenging aspect is removing the allocator from the template and supporting polymorphism. Radiant should not rely onnew/deleteas other libraries do. It is known that the (at least for MSVC)deletecauses the return register to contain the final pointer that needs to be freed after destruction. The original approach hoped to solve this withDestrPtrbut that did not prove useful.Proposed implementation details (optional)
No response