Really, you should make that connection an instance variable or private property, and then ARC it.
发自我的 iPhone 在 2013-2-5，18:06，Richard Frith-Macdonald <[email protected]> 写道： > > On 5 Feb 2013, at 09:42, Riccardo Mottola wrote: > >> Maxthon Chan wrote: >>> Just an idea, will ARC work? >> I don't know what it ARC would do in this situation, perhaps knowing >> that can help me putting the rlease in the correct place. I don't >> like/use it. In any case I want to understand what should be done with >> the connection. >> I don't hitnk this is a seirous error, but I want to understand. > > I expect if you used ARC, your program would fail rather than leaking. > The reason is, the compiler would see the instance variable go out of scope, > and release the NSConnection object ... so your code would be unabel to > accept incoming messages. > > The rules here are nothing special ... you need to retain an object until you > no longer want to use it. > In this case you say you want to keep the connection until the program ends > (so you can get messages from other apps), so the correct behavior is to keep > the object retained until the program ends ... which is what your code does. > The compiler is warning you because it sees the variable go out of scope (at > which point it becomes impossible for you to release it), but that's harmless > because you never want to release it. > > That being said, the compiler is warning you about a bad practice ... you > really should use a global variable or instance variable. > Not only will doing that avoid the compiler warning, it will also allow you > to release the connection explicitly on or before program termination. > > I like to invalidate and release connections immediately before shutdown, in > order to ensure that messages from other apps don't arrive while in the > process of shutting down. If your app has a complicated clean-up process > when it shuts down, an incoming message at that point could mess things up, > so it's simpler to stop accepting messages and then do other cleanup. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
