Re: POC destructors? (was Re: bogus retain via NSEnumerator)

[Helge Hess]

On 23.04.2004, at 08:45, Ben Golding wrote:
> > Of course not.  I balance my retains and releases, I use -release 
> > when I want to get rid of something immediately, and I use 
> > autorelease when
> > something else might want to keep the object in question around.  In
> > other words, I follow the published rules for retain/release.
> This discussion left me wondering how you can be sure when a program
> using garbage collection can know when an object is finally released.
>
> If I have a class that opens a file in it's init method, like:
...
>    - (void)dealloc
>    {
>       fclose(_fp);
>       [super dealloc];
>    }
...
> How can I know when the -dealloc method is called by the garbage
> collector?

(In a real, eg mark&sweep, GC) this is pretty much the same like with 
NSAutoreleasePools. If you really must know that an object is collected 
you trigger a full collection.
Yet its common practice to explicitly close the file with a different 
method for performance reasons. But this is basically the same with 
NSAutoreleasePools since you usually don't want to wait till the pool 
is released (or add thousands of nestd pools ...). If you deal with a 
scarce resource, you close it explicitely.

> If I create a lot of files using my class, how can I get POC
> to call the destructor so I don't run out of file descriptors?

OK, the context switches here, before you asked about GC. As far as I 
know POC has no garbage collector but just automatic RC, so this is 
different.

I would expect (but don't know for sure), that -free is called on 
dealloc. And because it is just RC all the semantics are pretty 
similiar to NSObject only using retain/release.

So if you wouldn't have all the drawbacks of automatic RC, POC actually 
works better for the thing -autorelease tries to solve (because it 
doesn't need to delay the deallocation). Indeed it (in theory) solves 
the issue you have with your file pointer in the best possible way 
(without adding an explicit -close method).

The NSObject memory management has its main advantages because its 
implemented as a regular ObjC library, so it doesn't require 
modification in the compiler nor in the language itself. Since it is 
explicit, it also makes it much easier to integrate with plain C (and 
after all thats one of the major points behind ObjC).

> One advantage of the autorelease pool mechanism is that when I send a
> -release message to an object and there are no other references, I know
> that its -dealloc method will be called then and there.

Which is wrong, thats exactly the drawback of an _autorelease pool_. 
You describe the advantage of RC without autorelease, which is exactly 
what POC does.
A different object could have called -autorelease before, so your 
object lives until the next pool release which is usually at the end of 
the runloop.

The major reason for autorelease is to add an abstraction to RC which 
makes dealing with temporary objects and return values mentally easier. 
And the major advantage is that it works without modifying the 
environment which most other memory management schemes require.

Greets
  Helge
--
http://docs.opengroupware.org/Members/helge
OpenGroupware.org