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.

On Mon, Mar 23, 2015 at 6:00 PM, Olaf van der Spek wrote:

On Sun, Mar 22, 2015 at 11:04 PM, Jakob Riedle wrote:

...

Furthermore it always is owning, even though ownership is shared in between instances.

A null-deleter would make it basically non-owning..

Right, and with a custom deleter, I believe, one can implement what flex_ptr provides. However, this looks like misuse to me since unique_ptr is supposed to imply unique ownership.

On Tue, Mar 24, 2015 at 11:14 AM, Olaf van der Spek wrote:

On Tue, Mar 24, 2015 at 8:12 AM, Andrey Semashev wrote:

...

On Mon, Mar 23, 2015 at 6:00 PM, Olaf van der Spek wrote:

...

On Sun, Mar 22, 2015 at 11:04 PM, Jakob Riedle wrote:

...

Furthermore it always is owning, even though ownership is shared in between instances.

A null-deleter would make it basically non-owning..

Right, and with a custom deleter, I believe, one can implement what flex_ptr provides. However, this looks like misuse to me since unique_ptr is supposed to imply unique ownership.

We're talking about shared_ptr.

Oh, right, sorry.

On Wed, Mar 25, 2015 at 8:55 AM, Jakob Riedle wrote:

...

A null-deleter would make it basically non-owning..

That doesn't solve Efficiency, but it allows for non-owning shared_ptr's. Thank you!

It doesn't, however, solve the underlying safety issues. Smart Pointers tend to be smart in two ways: - track ownership to correctly delete object - be safe With flex_ptr (or shared_ptr with custom deleter), how do you know that a non-null flex_ptr is pointing to valid memory or not. Or if it is valid on this line, but not the next, due to threading or something. Tony