Edit
I assume that the code below would suggest that I have an overloaded version of addChild () that accepts Sprite already wrapped in unique_ptr, where accepting ownership will be fine. Just thought I mentioned this earlier than anyone else. :). I have compiled all the code here after a very long day, so please take it as a quality of pseudo code intended only to demonstrate the problem.
Original question
I am writing a framework that has a display list, parents / children, etc. I think that using unique_ptr<Sprite>, for example, is a way to go here, because when you add a child to the parent display object, it is only logical that now the parent becomes the sole owner of this child.
However, there are methods available, such as getChildAt(index), getChildByNameetc., which, I believe, should return the value of a link or pointer, since these methods are simply designed to expose the child to operations, and not transfer ownership.
Finally, the problem and the cause of this issue are in the following situation. Let's say we have two objects Spritethat are children of the root of the display list, Stage. Say we have a third sprite child.
Stage newStage;
std::unique_ptr<Sprite> parentOne(new Sprite);
std::unique_ptr<Sprite> parentTwo(new Sprite);
newStage.addChild(parentOne);
newStage.addChild(parentTwo);
std::unique_ptr<Sprite> someChild(new Sprite);
parentOne->addChild(someChild)
Now, somewhere else, say, in the code base of the game, or in any case, using this structure, someChildgets access through getChildAt(int index);.
Sprite& child = parentOne->getChildAt(0);
It would be perfectly legal if the following happened.
parentTwo->addChild(child);
The method addChildhandles the removal of the child from it by the previous parent, if the parent exists, so that the new parent can now make this child part of its display list section.
child (ren) , ( , getChildAt()), . unique_ptr .
, , ( ) , (, , ). , , , , .
, . , ?
void Sprite::addChild(Sprite* newChildToOwn)
{
}