Is it valid to say that a Getter is the owner of the instance variable? Or who owns it?

Question

Actually I would say: yes, the Getter is the owner. So anyone who calls the Getter is not responsible for freeing the memory. Or more precisely, the object itself is the owner, but the Getter acts as a delivery mechanism of the instance variable to others. Is that right, or did I get that wrong?

Answer 1

Essentially you are correct, but its just a matter of convention. As long as your convention is applied consistently, and everyone working on the project agrees to that, then you're golden.

Where you may run into trouble is if a caller caches a pointer to some memory it gets from an accessor and then the object is destructed and now the pointer is dangling.

Answer 2

It depends.

You should decide on object ownership policies. But in general, if a object is a sub-object (a member) of another, the object it's part of is responsible for its lifetime, and (generally) clean it up it its destructor.

Handing out memory to be cleaned-up by the caller is generally frowned on. In C, libraries that must allocate memory for callers (say, X Windows libs, or a C API for a database client) will hand out an opaque pointer, which must be destroyed by the caller by calling another library function:

 Window foo = APIcreateWindow();
 APIsetupWindow(foo, x, y, z );
 AOIshowWindow(foo);
 APIdestroyWindow(foo);  //forgetting to call this leaks memory

In that (hypothetical) code, Window is actually a typedef for a pointer to struct; APICreateWindow allocated memory for the struct, APIdestroyWindow calls free on it, after doing other API book-keeping.

In C++, we'd probably hand back a smart pointer, that destroys itself when nothing else refers to it.

Answer 3

Since you are asking about Cocoa, which uses a reference-counting system, there is no such thing as "the" owner. Everyone with a retaining reference is a partial owner, responsible for releasing their reference. When the last reference is released, the object is deallocated.

It is the case that by convention getters do not give the caller a retaining reference, but that doesn't mean that a caller couldn't choose to explicitly retain an object.

Answer 4

It makes more sense to talk about objects, not methods, owning objects.

Quite often, the object that the getter is being called on is the owner of the object being returned, because the return value is an instance variable:

• (Foo*) foo { return _foo; // my instance variable }

However, it's also common for a getter to create a temporary object that's been autoreleased, and return it:

• (NSString*) sizeStr { return [NSString stringWithFormat: @"%d", self.size]; }

In this case, that object (the NSString) doesn't really have an owner, except perhaps the current autorelease pool, which will release it when it exits.

The important rules to remember in (non-GC) Cocoa programming don't have to do with ownership per se, but with when you have a reference to an object (that you'll have to release at some point) and when you don't.