XPCOM ownership guidelines

If you made it, you own it.

...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.

Needing it isn't, by itself, a valid reason for owning it.

You don't own an object because you need it. In fact often you own it because it needs you.

If you own it, it shouldn't own 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.

You don't need to own it if it's lifetime is guaranteed to be longer than yours.

As for instance, when it owns you.

Parents own their children (and not the reverse).

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.

Containers own the things they contain (and not the reverse).

Use 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.