bug-gnustep
[Top][All Lists]
Advanced

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

Re: [PATCH] Fix NSMenu retainCount problem


From: Alexander Malmberg
Subject: Re: [PATCH] Fix NSMenu retainCount problem
Date: Sat, 07 Feb 2004 15:47:39 +0100

Quentin Mathé wrote:
> the user shouldn't have to know the framework implementation. In other
> terms, correct objective-c memory management needs to support this rule
> : sending a message to an object should never induce increased retain
> count for this object.

I don't think this rule should be adopted. It's blatantly false for a
huge number of methods. While I can see that it would be useful in some
odd cases, the huge number of exceptions would make it difficult to rely
on. Cascading exceptions would make things even worse. For example, note
that methods implemented like:

-(NSString *) uppercaseString
{
        if (!self_contains_lowercase_characters)
                return [[self copy] autorelease];
        else
        {
                /* create new string, etc. */
        }
}

violate this rule and would have to rewritten in a less clear and less
efficient way.

The library should be free to autorelease objects. Library methods
should use their own autorelease pools if they autorelease a "large"
number of objects, and must always use one if the number of autoreleased
objects is unbounded. However, in the end, when the method returns, the
number of autoreleases on the objects that have been involved is
unspecified.

If you're relying on exactly when -dealloc is called for an instance
(which should be very rare), you need to explicitly manage autorelease
pools to ensure that there are no pending autoreleases. Alternatively,
you can split out the necessary "invalidation" from the -dealloc (like
eg. -base's NSConnection).

- Alexander Malmberg




reply via email to

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