On Fri, Mar 13, 2009 at 1:30 PM, Paul Sanders <p.sand...@dsl.pipex.com> wrote: > That's very interesting, I didn't know that attribute existed. I imagine > that post-dates autorelease pools by some years.
It's a relatively new GCC-ism. > But most objects returned > by framework functions are autoreleased which means you can only get rid of > them by bracketing them with an autorelease pool. If you're using NSApplication, you already have an autorelease pool. If you need it cleared more frequently, then yes it's your problem to create a new one. > This bugs me somewhat and > is obviously less efficient than just throwing them away when you are done > with them. No, it's not. Without any sort of management, you'd leak memory like crazy in situations where neither the caller or the callee can release the object. > But it does let you pass @"string" as a function parameter I > suppose without having to release it afterwards. @"" strings are baked into your binary as instances of NSConcreteString. They are not autoreleased. > Still can't say I like it > much. Well at this point, the only useful advice anyone can offer you is "Deal With It." Academic discussion on the merits of autorelease pools unfortunately won't help your project. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
