[Scott_H]

I've been reading the "Objective C" book that Apple has on the dev' site and have some questions. I know C and have been using it for a while. I also know/knew C++ so OO programming is not new to me. The Objective C book is okay but it's too much about OO programming and not enough about how to get **** done using Objective C. So here's my questions coming from a C background.


In C you define a structure and can make pointers to them and allocate them and .... like this.

SomeStruct *mydata;
mydata=malloc(sizeof(SomeStruct));
mydata->somefloat=0.0;

or maybe

SomeStruct mydata;
mydata.somefloat=0.0;

or maybe

SomeStruct *allmydata[100];
for(i=0;i<100;i++) allmydata[i]=malloc(sizeof(SomeStruct));


Is it the same way in Objective C? Like this.

SomeObj *mydata;
mydata=[[SomeObj alloc] init];

or maybe

SomeObj mydata;
[mydata init];

or maybe

SomeObj *allmydata[100];
for(i=0;i<100;i++) allmydata[i]=[[SomeObj alloc] init];


Is there some way of "getting things done" in Objective C that I don't know about? How about linked lists? I use them a lot in C and C++. Do Objective C programmers use them?

[mr_sonicblue]

That book is about the differences between C and Objective-C which, essentially, is the Object-Oriented capabilities of Object-C. There are two O'Reilly books coming out in May that will provide step-by-step guides to learning Cocoa and Carbon. Until then you have Apple examples and tutorials and the explaination I'm about to attempt. Watch out!

All classes in Object-C are subclasses of NSObject, which defines some key methods for allocating memory, releasing memory, and indentifying its own class, etc. Each class has a class object (of the same name) that allocates memory and creates temporary instances of an instance object of its own class type. You typically allocate memory for an object like so:

[NSNumber alloc]

This returns a temporary NSNumber instance object that will be released if a reference to it is not stored. We can do that like so:

NSNumber * myNumber = [NSNumber alloc];

You then have to initialize the instance object. The method names to do so are different from class-to-class, but always begin is 'init'. Here's an example using NSNumber:

NSNumber * myNumber = [NSNumber alloc];
myNumber = [NSNumber initWithFloat:5.2];

Or more simply:

NSNumber * myNumber = [[NSNumber alloc] initWithFloat:5.2]];

You can then use your object as you please:

myString = [myNumber stringValue];

You can also quickly produce temporary, initialized objects using factory methods in class objects which can be stored, but are often used as function/method arguments:

myNumber = [NSNumber numberWithInt:2];

OK, I hope I didn't confuse you more .

You can use linked lists, but a NSArray, NSMutableArray, NSDictionary, or NSMutableDictionary would be far more efficient for managing groups of different objects (since the objects they store are randomly accessible). You can when pulling an object out of one of the above, you can store it generically and check what class it belongs to like so:

id myObject = [myDictionary objectForKey:@"whatever"];
Class myObjectClass = [myObject class];

------------------

[Scott_H]

This returns a temporary NSNumber instance object that will be released if a reference to it is not stored.

Is that true? I hadn't read that? I thought I read you have to free stuff in Obj-C?

[sadie]

Yeah, how does memory get freed in objc? Where can i find more info about it? And did i hear somewhere there was a fiddle to gcc that could make it garbage collected?

[mr_sonicblue]

I don't know completely for sure. But, I'm pretty sure an object is released when there are no more references to it. This can be overridden with:

[anObject retain];

And restored with:

[anObject autorelease];

Or explicitly released with:

[anObject release];

Can someone who knows for sure tell us if this is right, please?

------------------

[parallax]

Originally posted by Scott_H:
Is it the same way in Objective C? Like this.

SomeObj *mydata;
mydata=[[SomeObj alloc] init];

That works

or maybe

SomeObj mydata;
[mydata init];

No way to statically allocate classes (as far as I know). That should flag an error. Every object's a pointer.

Is there some way of "getting things done" in Objective C that I don't know about? How about linked lists? I use them a lot in C and C++. Do Objective C programmers use them?

Linked lists can be implemented just like in C, but Foundation (a bunch of prebuilt classes) includes NSMutableArray, a linked-list-type thing.

A whole section of the ObjC book talks about memory.
I believe a retain increases the ref. count, release decreases it, autorelease marks it for later release, dealloc de-allocates the object, and when the ref. count is <= 0, the object is deallocated.

But for the most part, you won't have to worry about deallocating or explicitly releasing things.

[Scott_H]

Ahhh parallax. Just the info I needed. I'll check out those NS functions. I looked at NSSet but it didn't seem very fexible to me. Maybe NSArray is what I needed.

[Rick1138]

Yes,an object is released when the reference count equals zero.There is a good discussion of this complex topic available on page 88 of the PDF Discovering OPENSTEP: A Developer's Tutorial,which is available at http://developer.apple.com/techpubs/...cy/legacy.html

[ali]

Here are the object ownership guidelines in Cocoa, starting with the most important:

1. Objects returned from method calls should not be freed by the caller unless the method is a "new", "alloc", or "copy" method. (This includes variants such as mutableCopy or allocWithZone:.)

If you want to hang on to an object returned by a method, retain or copy it, and when you no longer need it, release it.

2. If you want to use the same convention when returning objects from your own methods, and the method is not "new", "alloc", or "copy", autorelease objects which you had to allocate and have to return to the caller. Autorelease marks objects to be automatically released "later". If you got the object from some other method (not a new, alloc, or copy), then you can just return it up the chain.

3. Along the same lines, when calling a method, ownership of arguments is not transferred; instead, the called method is responsible for retaining the argument if it wants to hold on to it.

There are two additional things to note with this:

Some methods hold on to the object arguments without retain/releasing it. This is effectively a weak reference. Examples of these include setDelegate: and setTarget:, whose arguments are usually "entity" objects (documents, windows, etc) rather than "value" objects (strings, etc). This turns out to be a reasonable guideline, as retain loops between entity objects usually lead to circular references. (Concepts of "entity" and "value" objects are not part of the API, just guidelines for how objects are used.)

The other case is that sometimes the called method might use "copy" to hold on to the object rather than "retain". These are equivalent as far as object ownership rules; but the difference is that copy effectively makes a true copy, while retain holds on to the original object. For some value objects, such as strings, numbers, etc, copy is the right thing to do, and it protects you from holding on to a mutable object which might change later.

Ali



[This message has been edited by ali (edited 04-03-2001).]