What restrictions exist when setting child names / tag?

What restrictions exist when setting child names / tag?
0.0 0

#1

Should be a pretty simple answer to this. I’m using the name facility to track child objects of nodes and then using that name later to retrieve them. From looking at the code I can’t see any type of checking for duplicate names and I’m also wondering whether the names need to be globally unique or not.

Will making all of the child names unique only to the parent Node be an issue? For instance if all children of all Nodes have the same names e.g. “1”, “2” etc


#2

From my experience duplicate names in one parent won’t crash game, but it’ll have trouble which one should it return when getChildByName will be called. But you always can iterate all children using getChildren().


#3

Yep, that’s what it looks like to me from the code too. I think it’ll just return the first child with the specified name if there are duplicates.

Any ideas about global uniqueness of names?


#4

Regarding childName / childTags. What’s the best practice for that? Using it or hold a reference to the node as class member? Any pro/cons would be fine.

My concern is, that a dynamic lookup could be significant slower (in large layer/scenes) than holding a direct pointer to it.


#5

I’m using a lot of nodes, which have children with the same names - it doesn’t break anything. I’m using it all the time.

Sure, using getChildren() and getting throught all children is slower then getChildByName, which looks like this:

Node* Node::getChildByName(const std::string& name) const
{
    CCASSERT(!name.empty(), "Invalid name");
    
    std::hash<std::string> h;
    size_t hash = h(name);
    
    for (const auto& child : _children)
    {
        // Different strings may have the same hash code, but can use it to compare first for speed
        if(child->_hashOfName == hash && child->_name.compare(name) == 0)
            return child;
    }
    return nullptr;
}

holding reference is again faster than getChildByName, but you have to have tousands of nodes to maybe see any difference (yet rending them will K.O. performance).


#6

No, the name is not required to be unique, it is just a helper to retrieve a node. You should make it unique by self. Indeed, in cocos2d-x, there is not a data hold all nodes, it is holed in parent/child relation.


#7

The difference between childName based retrieval from the parent and just holding a reference is that the childName method is tolerant to the case where the child no longer exists. If this is all within the same scope and you can guarantee the Node will always exist then holding a reference is fine, otherwise it’s important to use the name and the parent so you don’t use a dangling reference.

My assumption would be that the child Nodes would be stored in a binary tree type structure so retrieval of a child Node by name would log n time and even with a more basic implementation with a list would be linear time to find a child. Searching is done only on the immediate children so you’d need to have a LOT of child Nodes for this to be a problem (probably several thousand and then finding them by this method frequently).


#8

Thanks for the confirmation on the behaviour :slight_smile: