Re: macros

[David Relson]

At 10:38 AM 2/23/01, Helge Hess wrote:
> David Relson wrote:
> > The macros have different definitions depending on the environment.  I
> > don't recall all the particulars, but I remember seeing one set of
> > definitions for garbage collection and another set of autorelease pools.
>
> Exactly. GC was the initial reason to introduce the macros.
>
> > While looking at the macros and their usage, I did notice an oddity:  In
> > approx 6 modules, both AUTORELEASE and RETAIN are used.  For example in
> > NSTimeZone.m, the following lines appear:
> >
> >          zone = AUTORELEASE(RETAIN(defaultTimeZone));
> >          zone = AUTORELEASE(RETAIN(systemTimeZone));
> >
> > These seem really odd.
>
> No, this isn't odd at all. This would be odd and a NOOP:
>
>   RELEASE(RETAIN(defaultTimeZone));
>
> AUTORELEASE ensures that the object will be life in the current
> execution context (method/return value) / autoreleasepool transaction.

I assert that there's no reason for the 
AUTORELEASE(RETAIN(defaultTimeZone)).  Ensuring the existence of the object 
is good, but this doesn't do it. For simplicity let's assume the object is 
only used once:

Let's think about what happens if neither AUTORELEASE nor RETAIN is 
used.  In this case the defaultTimeZone is simply returned to the user 
program.  If the user program doesn't release it, all is good.  If the user 
program releases it, then the object will get deallocated, which is wrong.

If instead, we have AUTORELEASE(RETAIN()) and the user program releases it 
the object will be deallocated and, when the program gets to releasing the 
autorelease pool it will attempt to release a deallocated object.

In both cases, there's trouble if the user program releases the 
defaultTimeZone.  The AUTORELEASE(RETAIN()) does not ensure safety.

> > First, using both RETAIN and AUTORELEASE gives an
> > expensive NOP - their effects cancel one another (in an involved,
> > time-consuming manner).  Second, with NextStep it was considered a mistake
> > to call autorelease twice for the same object.  Tracing through the code, I
> > found 3 occurrences of the defaultTimeZone in the autorelease pool.
>
> You can call autorelease 100 times and it's still not a mistake, neither
> on NeXTstep (with Foundation) nor on GNUstep - as long as it happens
> balanced.

True, you CAN autorelease many times.  NeXTSTEP also has a mechanism for 
checking for double autoreleased objects, +[NSAutoreleasePool 
(NSAutoreleasePoolDebugging) enableDoubleReleaseCheck:(BOO)enable].  I 
assert that this mechanism wouldn't have been implemented if it wasn't useful.

Cheers!

David

--------------------------------------------------------
David Relson                   Osage Software Systems, Inc.
relson@osagesoftware.com       Ann Arbor, MI 48103
www.osagesoftware.com          tel:  734.821.8800