Tobias Oberstein wrote: > in the nsCOMPtr's user manual, it reads .. > > "There is no need to AddRef parameters, as they are guaranteed to live > as long as the function call." > > that puzzles me: of course a "nsISupports* ifcPtr" in _itself_ will live > that long, because e.g. C++ guarantees it .. but for the obj it points > to there is no guarantee of any kind, isn't it? >
What you are worried about is the life time of the object pointed to by a inteface pointer. There is a guaranteed that all XPCOM object will exist until the last reference to them is owned. So, in your example, the caller had to have a reference to this object. A function does not need to explictly AddRef() an |in| interface pointer. Now this guarantee calls for all code to handle your |ifcPtr| "correctly". Basically, it means that no one can call delete() directly on this interface pointer. They may only use Release() to end the life time of an object. If the entire system obeys this rule, then there is no problem. Of course, there is a whole field of understand about reference count balancing and ownership. It is tricky to understand and harder to get right. (or maybe that is the other way around.) There are plenty of place in the mozilla source base which have sticky ownership problems. (do an LXR searce for "KungFoDeathGrip"). In general, if the system stick to only addref and release of xpcom objects, there is no problem. I have traced too many problem down where parts of a system treated an interface pointer with AddRef/Release, and other parts decided to call delete directly. This basically results in what you are talking about, in the middle of your function, |ifcPtr| suddenly becomes garbage. Does this make sense? Doug Turner [EMAIL PROTECTED]
