Yes and no. You would end up releasing the string memory but "leaking" the NSAutoreleasePool object into memory by using drain instead of release if you ran this under a garbage collected (not memory managed) environment. This "leak" simply makes the instance of NSAutoreleasePool "unreachable" like any other object with no strong pointers under GC, and the object would be cleaned up the next time GC runs, which could very well be directly after the call to -drain
:
drain
In a garbage collected environment, triggers garbage collection if memory allocated since last collection is greater than the current threshold; otherwise behaves as release.
...
In a garbage-collected environment, this method ultimately calls objc_collect_if_needed
.
Otherwise, it's similar to how -release
behaves under non-GC, yes. As others have stated, -release
is a no-op under GC, so the only way to make sure the pool functions properly under GC is through -drain
, and -drain
under non-GC works exactly like -release
under non-GC, and arguably communicates its functionality more clearly as well.
I should point out that your statement "anything called with new, alloc or init" should not include "init" (but should include "copy"), because "init" doesn't allocate memory, it only sets up the object (constructor fashion). If you received an alloc'd object and your function only called init as such, you would not release it:
- (void)func:(NSObject*)allocd_but_not_init
{
[allocd_but_not_init init];
}
That does not consume any more memory than it you already started with (assuming init doesn't instantiate objects, but you're not responsible for those anyway).