XPCOM ownership guidelines
...naturally. If you create a temporary object, obviously it's up to you to destroy it. That's a sure sign of ownership. If you create an object with a longer lifespan, you will own it until you give ownership away.
All "factory" and "getter" functions produce owning pointers.
Such a function is the perfect example of something that creates an object with a longer lifespan that itself, and gives away ownership (by producing a pointer that is already
AddRefed) --- in this case, to the caller. This is terrific for factory functions, but can be problematic for mere getters. It's unfortunate if you just needed access to it for a moment. In the latter case, caching the pointer you got back makes you a de facto owner. This may not be appropriate; and it may be hard to remedy without knowing if the object in question was truly created in response to your query.
You don't own an object because you need it. In fact often you own it because it needs you.
Even transitively. Or put another way: the ownership graph for any system should be acyclic. Anytime there is a cycle of ownership, there is a situation that isn't automatically handled by destructors. Special code must be provided and called to break the cycle before the participants can be individually released.
As for instance, when it owns you.
Though parents may not need to own their children. For instance, a tree may own all the nodes that are in it. All the nodes in the tree point to each other with non-owning pointers. In the simplest scheme, however, parents point to their children with owning-pointers, children point back to their parents with non-owning-pointers.
nsCOMPtrs to implement owning-pointers.
It's explicit, efficient, and fairly bullet-proof. It's easier to write `getter's and `setter's; and you don't need to put anything in your destructor.