gnustep-dev
[Top][All Lists]
Advanced

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

Re: Question about memory management


From: Maxthon Chan
Subject: Re: Question about memory management
Date: Tue, 04 Jun 2013 09:13:54 +0800

A side note about autocomplete, I always cross-develop GNUstep apps under OS X, just for that Xcode capabilities. I really should build a GNUstep/Linux toolchain and SDK for Xcode to use so that at least before ProjectCenter and Gorm is in good shape we can develop using Xcode on OS X and copy code over to a Linux box and remotely debug. It should not be that difficult to build cross-compiling binutils and LLVM/clang targeting Linux under OS X, and consist them into a SDK/toolchain for Xcode.

在 2013-6-4,上午8:58,Ivan Vučica <address@hidden> 写道:

On 4. 6. 2013., at 02:14, Maxthon Chan <address@hidden> wrote:

Can you compile it with -fobjc-arc and check again? Probably with ARC you can have some ideas.

When you're not sure how something is memory managed, compiling with ARC is probably a terrible idea.

Turning magic into even-more-magic doesn't help learning. :)

On 4. 6. 2013., at 01:33, Germán Arias <address@hidden> wrote:

GSAutocompleteWindow *window = [GSAutocompleteWindow defaultWindow];
[window displayForTextView: self];

I think I should release this window at some point. Maybe in
-dealloc or with a notification when app will close. But looking
at code in NSCoimboBoxCell.m, the GSComboWindow is not
released at some point. So, is this a memory leak? Or I don't
should worry about this. If I add a NSLog() in dealloc, this is
never called. So, I think this is a memory leak.

The method is named +defaultWindow; it does not include "alloc", "create", "new"; hence its retaincount is "+1 (-1)", which is how I denote "currently 1, but autoreleased once".

If the method name included "alloc", "create" or "new", the retaincount would be"+1 (0)", which is how I denote "currently 1, and not autoreleased".

+defaultWindow implementation should be approximately:

+defaultWindow
{
    return [[[self alloc] initXYZ:abcd] autorelease];
}

If it is not autoreleased, then that's the problem.

Since it's autoreleased, I'd advise retaining the window, and later releasing it where appropriate (after the window is closed) -- despite the fact that the window might be retained while it's displayed. I don't know enough about internals of NSWindow or management of NSWindows under GNUstep to think about that... at least not yet. (GSoC will, for me, prove interesting in that regard. :))

Anyway, if -release is never called, then I'd first wonder: how do you close the window? Apple's docs for the -close method state:

If the window is set to be released when closed, a release message is sent to the object after the current event is completed. For an NSWindow object, the default is to be released on closing, while for an NSPanel object, the default is not to be released. You can use the setReleasedWhenClosed: method to change the default behavior.
P.S. I'm really looking forward to whatever you're coming up with... it'll be far better than wrestling with inability to add GS coding standards to Vim, and then wrestling without autocomplete :-)



reply via email to

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