Re: Leaked NSString from class_getInstanceMethod
Kyle Sluder <[email protected]> Sat, 23 Jul 2011 10:19:04 -0700
| Newsgroups | gmane.comp.macosx.devel |
|---|---|
| Message-ID | <CANEs-cyd7rFRhd4UJkhVOuJb7oQue4NnkVpwZNTNctEt9yM7tw@mail.gmail.com> |
On Sat, Jul 23, 2011 at 10:14 AM, Christiaan Hofman <[email protected]> wr= ote: > I don't think the runtime (function, not method) should ever use any Coco= a methods and objects, because the runtime is called before the Cocoa class= es are properly setup and initialize. Calling any Cocoa from a runtime meth= od will almost certainly lead to problems, because the whole setup of Cocoa= itself will be mixed up. So I disagree that there's no such guarantee. Qui= te to the contrary, if such a guarantee would not exist, than logically the= whole runtime would be internally inconsistent and buggy by design. I cann= ot believe that would be the case. > [ snip ] > And I am using functions rather than Cocoa precisely because I know it's = fragile. I do know very well that you simply cannot use Cocoa in +load, tha= t's always dangerous, because +load can be called before Cocoa has been ful= ly set up and initialized. So also using my own autorelease pool in +load i= s dangerous, so I cannot even do what this comment suggests. > > What is also strange is that when I define a local autorelease pool, its = -addObject: method is never called. There's no guarantee that the runtime goes through the NSAutoreleasePool facade to get at the underlying autorelease service. --Kyle Sluder