Can you explain your envisaged use cases in more detail perhaps, and why you think shared_ptr/weak_ptr is not the right choice for those cases?
My use case is the following: I'm currently writing an Operating System. It offers a DOM-Like GUI-Tree. If, suppose you have an arbitrary program running, that program creates a textbox and appends it to its main program-window. To make sure, the textbox gets deleted, the program either has to hold a reference to it and delete the object as soon as the program terminates, or it tells the window to take care of the Textbox and delete it, as soon as the window closes. You can imagine, if there is big bunch of GUI elements, using shared_ptr for all children nodes in all parents, is serious memory overhead and slows down the whole program. [This is especially the case with my hardware only offering 4MB of RAM.] The flex_ptr class makes it very easy and comfortable for a programmer to indicate, whether they want to take care of an object, or transfer ownership to the DOM-like GUI-Tree. So, what this pointer wrapper really is good for: - It is for platforms with limited hardware (when shared_ptr is no option, that is with many embedded/restricted platforms) - When Ownership is not always intended - For platforms with C-integration, since often, C-Code owns an object and you cannot give that object to existing libraries that use shared_ptr or unique_ptr's, because they would require you to give up ownership, that your C++-Code never had. Additionally: Taking ownership again from the GUI-Tree is possible through the following pattern: class GUINode: flex_ptr<GUINode> removeChild( GUINode* node ){ Unbind the child from this node. return the reference that I had to the child. } If the returned value of the function is not used, the child gets deleted as the temporary value gets destroyed (in case it was owning). On the other hand, the returned value can be stored in a variable, when you want to unbind the child from the parent, without deleting it.