[BigZaphod]

I was wondering if anyone could help clear up the rules with memory management and objective C. In C and C++, it is fairly obvious to me when to call free or delete. In Objective C, I'm still not entirely sure. To put it another way: Is this a memory leak?
---

[msgThing setStringValue: [NSString stringWithFormat:@"counter val: %d", counter] ];

---
(msgThing is a NSTextField*, if that matters)

Thanks for any tips!

[Chuckit]

Originally posted by BigZaphod:
I was wondering if anyone could help clear up the rules with memory management and objective C. In C and C++, it is fairly obvious to me when to call free or delete. In Objective C, I'm still not entirely sure. To put it another way: Is this a memory leak?
---

[msgThing setStringValue: [NSString stringWithFormat:@"counter val: %d", counter] ];

Nope, not a memory leak.

Basically, with Cocoa, you don't generally delete objects yourself. You retain and release them. The general rule is that an object gets deleted when it's received one release message for every alloc, new, copy or retain message. If you haven't sent an object one of these messages, you shouldn't have to release it.

Cocoa Dev Central has an article on Cocoa memory management, if you're interested.

[Rickster]

Further illumination: +stringWithFormat: is a convenience constructor, which by convention returns an autoreleased instance. You don't need to worry about releasing it yourself, as the autorelease pool will clean it up later.

Another good reference for ObjC memory management: http://www.stepwise.com/Articles/Tec...-03-11.01.html

[smeger]

Basically, the rule is that every time you call 'retain' or 'alloc', you must guarantee that there is a code path that will be executed that has a corresponding 'release' or 'autorelease.'

That's it.

[BigZaphod]

Thanks for the help!

[Gametes]

I was surprised when I finally decided to read up on memory management that what had been the rule in C no longer applies to objects. namely:

Code:
- (void)method
{
int i = 3;
NSString *string = [[NSString alloc] init];
}

When this method completes, "i" is destroyed automatically by the program but "string" persists in a permanent unreferencable limbo known as a memory leak.

Why the double-standard?

Also, is it possible for me to create a category of NSObject which equates [class new] with [[[class alloc] init] autorelease]?
I am SO sick of writing it. Will that cause conflicts?

[proton]

Originally posted by Gametes:
I was surprised when I finally decided to read up on memory management that what had been the rule in C no longer applies to objects. namely:

Code:
- (void)method
{
int i = 3;
NSString *string = [[NSString alloc] init];
}

When this method completes, "i" is destroyed automatically by the program but "string" persists in a permanent unreferencable limbo known as a memory leak.

Why the double-standard?

No double-standard really. The variable string is a pointer to an NSString object. The variable string (that is the pointer) gets destroyed at the end of the routine, but not what it was pointing to.

This is exactly the same behaviour as say:

Code:
void foo (char *foo) {
   char *pointer;
   pointer = (char *)malloc(strlen(foo));
   /* might as well do something with our memory */
   strcpy(pointer, foo);
}
/* the memory pointed at by pointer has been leaked! */

That's how it should work :-)

Also, is it possible for me to create a category of NSObject which equates [class new] with [[[class alloc] init] autorelease]?
I am SO sick of writing it. Will that cause conflicts?

I wouldn't try it personally, a lot of things would be relying on the standard behaviour and things will probably crash in a lot of places...

- proton

[Ghoser777]

I was surprised when I finally decided to read up on memory management that what had been the rule in C no longer applies to objects. namely:

Code:
- (void)method
{
int i = 3;
NSString *string = [[NSString alloc] init];
}

When this method completes, "i" is destroyed automatically by the program but "string" persists in a permanent unreferencable limbo known as a memory leak.

Why the double-standard?

This will leak too, in pure C:

void randomMethod()
{
int *a = (int *)malloc(sizeof(int)*1);
}

As stated above, a holds a location in member - it's like a houses address, it tells you where the house is, it's not the house itself. So a goes out of scope, but it's just a pointer to the actual object, not the object itself.

Also, is it possible for me to create a category of NSObject which equates [class new] with [[[class alloc] init] autorelease]?
I am SO sick of writing it. Will that cause conflicts?

NSObject already implements +new, I would NOT suggest using a category to override the implementation - although it's possible, I could only imagine bad things happening with subclassess that override the method. +new already does +alloc -init. Why not add a category adding method +temp or +create or +make instead?

Isn't memory managment fun?

Matt Fahrenbacher

[Chuckit]

Originally posted by Gametes:
Also, is it possible for me to create a category of NSObject which equates [class new] with [[[class alloc] init] autorelease]?
I am SO sick of writing it. Will that cause conflicts?

It probably will cause conflicts.
But essentially every class out there has a convenience constructor named after the class (e.g. [NSDictionary dictionaryWithObject:object] is equivalent to [[[NSDictionary alloc] initWithObject:object] autorelease]), so it shouldn't really be necessary.
Also, I have to wonder why you're autoreleasing so much. It's more efficient (and in better keeping with the retain and release metaphor) to simply release an object when you're done using it.

[Angus_D]

Originally posted by Gametes:
Why the double-standard?

As others have pointed out, this is not a double standard -- the difference here is that you cannot allocate Obj-C objects on the stack.

[Gametes]

Originally posted by Chuckit:
Also, I have to wonder why you're autoreleasing so much. It's more efficient (and in better keeping with the retain and release metaphor) to simply release an object when you're done using it.

It's for variables that only exist in the method. I just want them to die a natural death after the method completes.
I'm one of those who hates memory management; iy makes my code ugly

[iJed]

Originally posted by Gametes:
It's for variables that only exist in the method. I just want them to die a natural death after the method completes.
I'm one of those who hates memory management; iy makes my code ugly

If you really hate memory management that much then you should program in Java rather than a C derivative.

[Gametes]

Well I really like the other features of Obj-C, like the core messaging syntax and dynamic typing and all that. I don't know all that much about Java, but Obj-C is the preferred language of Cocoa so that's what I'm going to use. It is simply unfortunate that memory management isn't like everything else in Obj-C: very flexible. Ideally I would expect that the programmer could flip a switch for "automatic/manual" memory management if they wanted to eke that little bit of extra performance out of the program by slaving over every variable... I do not care to, just as I never statically type anything and otherwise avoid commitment, specificity, and any extra typing whenever possible.

Besides, I can dislike one aspect of the implementation without having to abandon the whole thing.

[trusted_content]

Just read my Everything2 node. It should clear it all up for you quite nicely.