Pointers, am I using them correctly? Objective-c/cocoa

Question

I have this in my @interface

struct track currentTrack;
struct track previousTrack;
int anInt;

Since these are not objects, I do not have to have them like int* anInt right? And if setting non-object values like ints, boolean, etc, I do not have to release the old value right (assuming non-GC environment)?

The struct contains objects:

typedef struct track {
NSString* theId;
NSString* title;
} *track;

Am I doing that correctly?

Lastly, I access the struct like this:

[currentTrack.title ...];
currentTrack.theId = @"asdf"; //LINE 1

I'm also manually managing the memory (from a setter) for the struct like this:

[currentTrack.title autorelease];
currentTrack.title = [newTitle retain];

If I'm understanding the garbage collection correctly, I should be able to ditch that and just set it like LINE 1 (above)?

Also with garbage collection, I don't need a dealloc method right? If I use garbage collection does this mean it only runs on OS 10.5+? And any other thing I should know before I switch to garbage collected code?

Sorry there are so many questions. Very new to objective-c and desktop programming.

Thanks

Answer 1

I have this in my @interface

struct track currentTrack;
struct track previousTrack;
int anInt;

Since these are not objects, I do not have to have them like int* anInt right?

That would declare a pointer to an int stored somewhere else.

And if setting non-object values like ints, boolean, etc, I do not have to release the old value right (assuming non-GC environment)?

release is a message. You can only send a message to a Cocoa (or, in some cases, Core Foundation) object.

The struct contains objects:

typedef struct track {
    NSString* theId;
    NSString* title;

More precisely, it contains pointers to objects.

You can't ever have an object stored directly in a variable; you can only allocate it dynamically by sending an alloc message to a class, and receive the pointer to the allocated instance. Similarly, you can only send a message to a pointer to an object; you cannot and should not dereference a pointer to an object.

For these reasons, we almost always elide the “a pointer to”. We speak of the pointers as if they are the objects, but, in precise truth, they are not.

} *track;

That's correct if you want to declare the track type as being a pointer to a struct track. Generally, this will confuse people.

Lastly, I access the struct like this:

[currentTrack.title ...];
currentTrack.theId = @"asdf"; //LINE 1

So the previous line is line 0? ;)

I'm also manually managing the memory (from a setter) for the struct like this:

[currentTrack.title autorelease];
currentTrack.title = [newTitle retain];

If I'm understanding the garbage collection correctly, I should be able to ditch that and just set it like LINE 1 (above)?

If you're using garbage collection, then the autorelease and retain messages will do nothing, so yes, the plain assignment and the assignment with (ineffectual) release and retain messages are equivalent.

I do question why you're putting this information in a structure and not a model object, though.

Also with garbage collection, I don't need a dealloc method right? If I use garbage collection does this mean it only runs on OS 10.5+? And any other thing I should know before I switch to garbage collected code?

Yes: Read the Garbage Collection Programming Guide. It tells you everything you need to know, including the answers to the previous two questions.

As for pointers, you may want to read my pointers tutorial. The title says C, but everything in C is also true in Objective-C.

Answer 2

Correct, correct, no, yes, correct, yes, and Apple's Garbage Collection Programming Guide is a good read.

Answer 3

Although you seem to understand this stuff all right in general, I'd strongly recommand against storing objects in a struct. Getting proper memory management for that will be very troublesome — because even though the struct itself doesn't require memory management, the objects still do, and unless the struct is only ever accessed through a function API (essentially making it s poor man's object), you're going to have a tough time ensuring that happens. Like Peter said, that makes sense to be a model object.