discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The orca, GNUstep's mascot


From: Richard Frith-Macdonald
Subject: Re: The orca, GNUstep's mascot
Date: Tue, 29 Apr 2008 07:55:25 +0100


On 29 Apr 2008, at 07:39, Graham J Lee wrote:


Hi Gregory,

On 28 Apr 2008, at 22:52, Gregory John Casamento wrote:
Damn... yes, I was thinking of TEST_RELEASE.
[...]

Gregory John Casamento wrote:
RELEASE is a #define which does the standard checking that needs to
be done when doing a release.

In what way needs to be done? The scenarios for sending [obj release] are:
1. obj is nil; nothing happens.
2. obj is not an id; crash (if you're lucky).
3. obj is an id which does not respond to @selector(release), and has no forwarding mechanism; runtime exception. 4. obj is an id which responds to @selector(release) or consumes it in some other way; it does its stuff.

Case 1 is a special example of case 4, so case 2 needs to be tested for and some might argue case 3. But the macro is defined as:

#define TEST_RELEASE(object)     ({ if (object) [object release]; })

which doesn't provide that.

Thanks,

RELEASE was introduced to completely remove the call to -release in the case when gc was enabled. Apple have now effectively done the same thing by modifying the compiler to remove the call itsself... we went for a more portable solution, but as they control the compiler version being used, Apples decision makes a lot of sense.

TEST_RELEASE was added to optimise the common case of sending -release to nil when gc was not enabled ... the 'if (object)' test being much more efficient than a method call.

Neither optimisation is really important IMO, now that processors are *much* faster than they were when these macros were introduced. The overheads of calling -release are generally a much smaller proportion of the overall running time of a program than they used to be.

I think the ASSIGN, ASSIGNCOPY, and DESTROY macros are still worthwhile having as conveniences (and because they tend to prevent some common coding errors).







reply via email to

[Prev in Thread] Current Thread [Next in Thread]