Re: [boost] [SmartPointers] Determine interest in a new pointer wrapper class "flex_ptr"

Subject: Re: [boost] [SmartPointers] Determine interest in a new pointer wrapper class "flex_ptr"
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-23 07:46:56

On Monday 23 March 2015 10:19:00 Jakob Riedle wrote:
> > 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.

Perhaps I'm missing the point but to me it looks like a dangerous kind of 
pointer. You have to state clearly the ownership model for the elements of 
your DOM structure. Otherwise working with the structure becomes very error 
prone.

What happens if one piece of code creates an object and puts it into the DOM 
structure? Who owns the object (i.e. responsible for destroying it)? What 
happens when another piece of code obtains a reference to the object in the 
DOM? And what happens when whoever owns the object destroys it (while other 
references are still present)? Are multiple owners possible?

To my mind, if your data model allows multiple more or less persistent 
references to a single object you will have to go with shared ownership 
pointers - shared_ptr or intrusive_ptr, the latter possibly being more 
efficient. Otherwise you have to guarantee there's only one owner of the 
object and all other references never outlive the owner. Based on your 
description, I suspect, you can't give that guarantee.