[tennesseekevin]

I'm wondering why it is necessary to do the usual [[anObject alloc] init] call after declaring the object. Isn't this an extra, unnecessary step. Wouldn't it be implied in typing the object (i.e. NSObject *anObject)? I think I'm completely missing the point. What happens if I don't alloc and init? I imagine alloc has something to do with memory managment. But what about init?

Thanks for helping the ignorant.

[Angus_D]

No, it's not "implied" by NSObject *object -- all that says is "i want a pointer to an NSObject, and let that pointer be referenced by the identifier 'object'".

Alloc allocates memory for the object, init initialises the object's internal state. Objects can have other initialisers (e.g. initWithContentsOfFile, or whatever) to initialise them based on some other factors. If you don't alloc, you don't have an object. If you don't init, you don't have an initialised object.

[Chuckit]

Just as in plain C, NSObject *anObject doesn't declare an NSObject--it declares a pointer to an NSObject. It allocates the memory for this pointer (4 bytes), but not the data referenced by the pointer. Just as you'd have to malloc(sizeof(int)) if it had been a pointer to an int, you have to send an alloc message to NSObject.

When you alloc an object, all of its variables are set to 0. So you call init to have the object set itself up to a usable state. (Note also that init doesn't always return the same object that alloc did, such as with class clusters.)

[Mskr]

Chuckit: Just wanted to comment on one nit-picky little thing...

When you alloc an object, it just means that the memory has been reserved for that object on the heap, not that it's initialized to 0 (which would be a performance hit). When you alloc an object, you shouldn't touch anything for that object until you initialize it. Also, don't do things like:

Code:
-=-=-=-=- in CTSFoo.h

@interface CTSFoo : NSObject
{
    int a;
    int b;
}

- (int) a;
- (int) b;
@end

-=-=-=-=- in CTSFoo.m

@implementation CTSFoo

- (id) init
{
   if ((self = [super init]) != nil)
   {
         a = 0;
   }
}

- (int) a
{
   return a;
}

- (int) b
{
   return b;
}

If you were to call a from a newly alloc'd & init'd object, you'd get '0', just as you'd suspect. If you call b, you'd get garbage back, since that member variable was never initialized after being allocated. This is obviously very bad if you have pointer members and try to access them after you think you've init'd them, but you forgot... Or, even more evil, testing to see if they're initialized by comparing them to 0 or nil...

Just something to watch out for.

Oh, and btw, you can also do

Code:
NSObject *obj = [NSObject new];

as a shortcut for

Code:
NSObject *obj = [[NSObject alloc] init];

[Chuckit]

Going by Apple's documentation, I think my earlier statements were correct. Also, I just tested your example, and b was indeed initialized to 0.

[Angus_D]

Memory allocated for obj-c object structures is implicitly zeroed. This is in Apple's Obj-C spec, I think. Also, usage of +new is not recommended and not documented.

[smeger]

Just one more "me too" to mention that obj-c structures are indeed zeroed when alloc'ed. I make heavy use of this fact, as does Apple. If you look at any boolean flags in Cocoa, they're all set up so that the default state corresponds to 'NO'. This is so they don't have to double-initialize them.

[Mskr]

Alrighty, I stand corrected on the initialization to 0 comment! I guess I didn't really need three people to tell me I was wrong, but ok...

However, +new is indeed documented, and there's nothing wrong with using it. It's a class method of NSObject. I don't see anything there that says you shouldn't use +new, or even that you shouldn't override it in your own subclasses. It just sounds like you shouldn't override it if you're just doing what plain old alloc & init do.

Anyway, the reason that I was misguided on the initialization thing was that I swear I've had problems when relying on pointer class members and doing lazy initialization. When I would check for equality to nil, it would return false, but I had not explicitly initialized the member, either. When I went back and 'nil'-ed the member in -init, everything was fine. But nil == 0, so what's up with that?

[smeger]

Originally posted by Mskr:
Alrighty, I stand corrected on the initialization to 0 comment! I guess I didn't really need three people to tell me I was wrong, but ok...

Sorry

I basically just jumped into the fray because I like the "default flags are NO" thing and wanted to draw attention to it.