1

I'm currently learning objective-c and I'm currently training with NSTableView.

Here is my problem :

I have linked my tableview to my controller through Interface Builder so that it has a datasource, I have implemented NSTableViewDataSource protocol in my controller and I have implemented both -(NSInteger) numberOfRowsInTableView: and -(id) tableView:objectValueForTableColumn:row: methods.

I have created a raw business class ("person") and I succeeded to display its content into my NSTableView.

But then, I put some NSLog in my dealloc methods to see whether the memory was freed or not and it seems that my array as well as my "person" instances are never released.

here is my dealloc code in the controller:

-(void)dealloc
{
    NSLog(@"the array is about to be deleted. current retain : %d",[personnes retainCount]);

    [personnes release];
    [super dealloc];
}

and in my "person" class

-(void) dealloc
{
    NSLog(@"%@ is about to be deleted. current retain : %d",[self prenom],[self retainCount]);

    [self->nom release];
    [self->prenom release];

    [super dealloc];
}

When these deallocs are supposed to be called in the application lifecycle? Because I expected them to be called at the window closure, but it didn't.

In the hope of beeing clear enough,

Thanks :)

KiTe.

kite
  • 679
  • 2
  • 8
  • 19
  • Those `-dealloc` methods are never called? –  Apr 12 '11 at 13:40
  • Does your app only have this one view? – Black Frog Apr 12 '11 at 13:40
  • 1
    Just some advice about retainCount.. DO NOT depend on it. http://stackoverflow.com/questions/2020103/memory-management-in-objective-c – Joe Apr 12 '11 at 13:42
  • 1
    [self->nom release] should be [nom release] – Terry Wilcox Apr 12 '11 at 13:43
  • this is my only view yes. I mean I only have the default window with my NStableView. And the dealloc are never called (when I close my window, it should be the case right,) – kite Apr 12 '11 at 13:43
  • Also, is this a document-based application? –  Apr 12 '11 at 13:44
  • no, it's an app in its simplest form. a single standalone window – kite Apr 12 '11 at 13:45
  • @terry > it does the same, no? just an old habit of C# writing ^^ – kite Apr 12 '11 at 13:46
  • Do you have a custom window controller? –  Apr 12 '11 at 13:46
  • the controller is a simple class of mine, yes. it only has the 2 NSTableViewDataSource methods I said above, awakeFromNib (which works) and dealloc – kite Apr 12 '11 at 13:48
  • but anyway, shouldn't the release method (and then dealloc) of the controller be called when I close my only window? – kite Apr 12 '11 at 13:51
  • @kite If you're learning a language, using bits of other languages is counter-productive. – Terry Wilcox Apr 12 '11 at 14:22
  • @terry I generally agree, but on this point does it really change a thing? cause I feel this is more easy to read/understand like I did .. but if there is a reason for this to be wrong, then I'll stop doing so in my code ^^ – kite Apr 12 '11 at 14:23
  • @TerryWilcox @kite There’s nothing implicitly wrong with using `self->ivar` AFAICT. In fact, some developers use `self->ivar` to make it explicit that they’re referring to an instance variable as opposed to an automatic/local one. –  Apr 12 '11 at 22:27
  • well, at least I wasn't doing it wrong :p thanks ^^ – kite Apr 13 '11 at 07:25

2 Answers2

4

I’m assuming you’re never releasing the window controller object that owns the (only) window. As such, the window controller and every top level object in the nib file are retained throughout the application lifecycle, including the window (and its views).

Since the window controller exists throughout the application lifecycle, it isn’t released, hence its -dealloc method is never called. And, since the controller -dealloc method is never called, its personnes array isn’t released.

The personnes array owns its elements. Since the array isn’t released, neither are its elements, hence the -dealloc method of the corresponding class/instances is never called.

  • ok that's what I thought. But is it ok finally? Because I've never retained the controller by myself (only linked it to the window through IBuilder). So the memory is never released in the end? – kite Apr 12 '11 at 14:04
  • @kite How did you link it to the window (I’m assuming you’re referring to the `window` outlet)? If the controller was instantiated in MainMenu.nib, then `NSApplication` owns it as well as any other top level objects in that nib file. –  Apr 12 '11 at 14:06
  • 3
    @kite The memory is reclaimed by the operating system when the application finishes. Since this is automatically done by the operating system upon application exit, the runtime doesn’t bother releasing (and hence sending `-dealloc` to) live objects. –  Apr 12 '11 at 14:07
  • ctrl + drag from the window to the controller --> data source. – kite Apr 12 '11 at 14:08
  • @kite Note that when you implement a ‘remove item’ feature in your application and remove an object from the `personnes` array, the `-dealloc` method of your person class (`Personne?`) will be called. –  Apr 12 '11 at 14:11
2

Don't ever use retainCount. The results are misleading at best. If you practice proper memory management practices, you'll be fine. Have you had any memory issues/crashes?

Community
  • 1
  • 1
kubi
  • 48,104
  • 19
  • 94
  • 118
  • not at all, I just wanted to see how the memory was released when I closed my window (which is the only window of my app). and even without displaying the retain count, the dealloc is never called anyway – kite Apr 12 '11 at 13:44
  • thanks for the advice. By making some research, I found it was to avoid in Appkit/UiKit apps. But is it still valuable in console app? – kite Apr 12 '11 at 14:30
  • 2
    @Kite Being a console app doesn’t change a thing. There are several factors to take into account in order to get useful information from retain counts, so in general it’s best to avoid them. If you’re curious, consider how interaction with Cocoa frameworks alters the retain count, how (and when!) autorelease pools alter the retain count, what’s the retain count of constant objects, and how multithreaded code affects the retain count. ;-) –  Apr 12 '11 at 14:37
  • so in the end they give us the feeling of controlling the whole memory management, but it is not totally the case (not like C/C++) ^^. well, let's just care about the objet ownership then, and I'll take a look to these points when i'll be a bit more used with this language ^^ – kite Apr 12 '11 at 14:43
  • 1
    You control everything that you need to control. The numbers you get back from `retainCount` are interesting, but almost entirely useless. – kubi Apr 12 '11 at 14:54
  • "You control everything that you need to control." that's what I meant when I said "let's just care about the objet ownership then". ^^ – kite Apr 12 '11 at 14:56