https://xkcd.com/386/ <https://xkcd.com/386/>
With that out of the way, autorelease pools don't have much to do with garbage collection - in fact the document that you've linked to specifically outlines the following with regards to autorelease pools and GC: > In a garbage-collected environment, there is no need for autorelease pools. > You may, however, write a framework that is designed to work in both a > garbage-collected and reference-counted environment. In this case, you can > use autorelease pools to hint to the collector that collection may be > appropriate. There isn't anything functionally wrong with the code that you have specified, unless you count not letting the compiler decide what should be done there as being a functional problem (that's how ARC actually works - it's just telling the compiler to generate the necessary pools, retains, releases, deallocs, and so on as it finds cases where it's needed). It wouldn't even work under a GC or otherwise trigger the GC to do much of anything unless I drained the pool - at best it would provide a hint to the GC, and at worst it would no-op. Even then, the viewer still doesn't use GC. Instead I had it manually allocate and deallocate objects as needed, with the exception of the occasional autorelease pool. To my knowledge, manual memory management is still supported under OS X 10.12, and ARC is still opt-in (or opt-out, depending on what version of Xcode you created the project with). A few tests on my end still show that NSAutoreleasePool is still valid, as is autorelease and autorelease blocks, when using the latest beta of macOS 10.12 and Xcode. Now! That being said, at the time that the code was written ARC wasn't well supported under OS X 10.6, which was the viewer's minimum target at the time. Of course as time has went on, the viewer's minimum requirements have changed. It wouldn't be the worst idea to revisit it, especially since my own coding style and skills have improved since I wrote the original code for the Obj-C port of the viewer's frontend, but at the same time it doesn't really add much value given that you're basically talking about making the compiler do something that's already being done manually. You won't see any massive performance gains. You won't see the viewer magically shed tens of megabytes off of its memory footprint. Sure you could argue that if Apple decides to make ARC the law of the land with no MRR being permitted in sight there could be some value there, but there's no indication of that happening. You would be doing it literally to future proof something where there's no indication of there being a need to do so, and only for any Objective-C objects - C++ objects are untouched by ARC. If you'd like to continue debating how memory management works under Objective-C, and NSAutoreleasePool, release, retain, and dealloc's place in it, by all means! Feel free to email me directly, though I'd recommend reading this first <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html>. Though I doubt there's much interest on this list in watching such a thing. > On July 8, 2016 at 3:13:44 PM, Geir Nøklebye (geir.nokle...@dayturn.com > <mailto:geir.nokle...@dayturn.com>) wrote: > >> I cannot see there is anything “advanced” MRR (manual retain-release) going >> on in: >> >> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init]; >> >> insert your viewer code here >> >> [pool release]; >> >> >> That can’t be handled with @autoreleasepool, >> if you even need to handle it outside the main thread >> autoreleasepool >> >> >> In fact the above is a classic example of the old garbage collector in >> action. >> >> >> Geir, >> >> >>> On 8. jul. 2016, at 21.47, Geir Nøklebye <geir.nokle...@dayturn.com >>> <mailto:geir.nokle...@dayturn.com>> wrote: >>> >>>> Cinder Roxley said: >>> >>>> The viewer has never used the garbage collector so it?s not an issue. >>> >>> >>> >>> Why is it that in llopenglview-objc.mm, as en example, we have statement >>> like: >>> >>> NSOpenGLPixelFormat *pixelFormat = [[[NSOpenGLPixelFormat alloc] >>> initWithAttributes:attrs] autorelease]; >>> >>> or >>> >>> - (void)dealloc >>> { >>> [[NSNotificationCenter defaultCenter] removeObserver:self]; >>> [super dealloc]; >>> } >>> >>> while Apples ARC migration guidelines states: >>> >>> You cannot explicitly invoke dealloc, or implement or invoke retain, >>> release, retainCount, or autorelease. >>> >>> You can’t invoke dealloc. >>> >>> Custom dealloc methods in ARC do not require a call to [super dealloc] (it >>> actually results in a compiler error). The chaining to super is automated >>> and enforced by the compiler. >>> >>> >>> Or in llwindowmacosx-objc.mm we have code such as: >>> >>> bool copyToPBoard(const unsigned short *str, unsigned int len) >>> { >>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init]; >>> NSPasteboard *pboard = [NSPasteboard generalPasteboard]; >>> [pboard clearContents]; >>> >>> NSArray *contentsToPaste = [[NSArray alloc] initWithObjects:[NSString >>> stringWithCharacters:str length:len], nil]; >>> [pool release]; >>> return [pboard writeObjects:contentsToPaste]; >>> } >>> >>> Apple’s documentation specifically says how to rewrite this construct for >>> ARC. >>> >>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/index.html#//apple_ref/occ/cl/NSAutoreleasePool >>> >>> <https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/index.html#//apple_ref/occ/cl/NSAutoreleasePool> >>> >>> >>> So all this code needs to be rewritten to support ARC or it will not run or >>> fail on 10.12. >>> >>> >>> Geir Nøklebye, >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > <http://wiki.secondlife.com/wiki/OpenSource-Dev> > Please read the policies before posting to keep unmoderated posting privileges
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
