Is it really necessary to call init
after object allocation? I mean: in Java for instance if you don't call it (the constructor), it will be called anyway (the default constructor). In Objective C you can create an alternative constructor (like Java) and one of the things I see the most is self = [super init]
. I read: cocoawithlove article, but in the end it's not clear why we should make such assignment self = [super init]
. It just says that the [super init]
can return a different object, and then we must replace the self
with that new object. That wouldn't explain why we do it in first place.

- 714,442
- 84
- 1,110
- 1,523

- 652
- 2
- 7
- 23
-
according to the inheritance logic, you can override the methods of super class. if you override the i.e. `-init` method, the `-init` of super will never called. you make sure to call the method manually in your new `-init` method, it'll init your super class. if you wrote the super class and if you are 100% sure everything will be inited normally you could avoid to call super, but when you don't know anything about the super class, to miss to call the `-init` method of super is extremely dangerous, it might cause some private variable won't be inited and it cause unwanted behaviour or crash. – holex Sep 04 '12 at 13:37
-
possible duplicate of [Why should I call self=\[super init\]](http://stackoverflow.com/questions/2956943/why-should-i-call-self-super-init), [Wht to use \[super init\] in ObjC constructors?](http://stackoverflow.com/questions/9283004/) – jscs Sep 04 '12 at 20:01
3 Answers
is it really necessary to call init after object allocation?
Yes, it is necessary. To compare to Java, calling [super init]
(or some other designated initializer) effectively runs the superclass' constructor. This mechanism is provided for you in Java, but not in Objective-C. So it is not called implicitly in ObjC as it is in Java. In ObjC, you must call one of the superclass' designated initializers explicitly. If you do not call your superclass' initializer, your object will not be entirely initialized. This may result in no exhibited side-effects, or it could result in a completely unusable object which invokes undefined behavior.
why we should make such assignment self = [super init].
Right, alloc
creates an allocation (with zeroed memory) and sets the pointer to the class information isa
, but a superclass' initializer permits the superclass to exchange the instance with another which may be more appropriate. Typically, you would avoid doing this in your own subclasses. The other reason to perform this and the nil check is that it is the means an error is handled. In ObjC, exceptions are generally non-recoverable, so the conventional way to report an error to the subclass is to return nil
. That is why it is also important not only to assign self
, but also to test it for nil
.

- 104,054
- 14
- 179
- 226
-
But what the heck is returned from alloc? what does init(by default) do that makes the object usable? When i call init, i assume the default behavior is a chain of calls until the root class. Is that what happens? – BrunoMCBraga Sep 04 '12 at 14:30
-
@BrunoBraga a) think if it as the result of `calloc`, with the size large enough to accommodate the instance. the class' `isa` is set (e.g. used by the runtime to identify the class, access its selectors, and so on). without the `isa`, the objects would not be able to walk up the hierarchy. b) yes. since super's init is (er -- *should* be) called first, the class is constructed from the base up -- just like in Java. NSObject's init does not need to do anything special, but it is a contract you must fulfill. in fact, the docs say its NSObject init does nothing at present :) – justin Sep 04 '12 at 15:06
There is a big difference between Objective C and Java. Java is an interpreted language built from the ground up, while Objective C was built on top of C language. Anything that you can do in C is valid in Objective C as well.
Unlike Java, C (and by extension, Objective C) has "raw memory allocation". In Java, a call to new
automatically calls the constructor. The language makes it impossible to go around this mechanism. In Objective C, however, you can allocate raw memory. The memory does not contain a ready-to-use object at the time it is returned to you from alloc
- it is only partially prepared for use. The memory block has a reference count, and it provides enough space to fit your object, but it is not ready to receive messages that your own subclass has implemented. That is why you must call init
(or use new
, which combines alloc
and init
for you).
The if (self = [super init])
assignment/check lets you trap errors during the construction phase of your object. If your own initializer fails, you can set self = nil
to report the problem up the chain. Assigning a different object is far less common, but it could be done as well.

- 714,442
- 84
- 1,110
- 1,523
After allocation instance variables should be instantiated.
self = [super init]
refers to initialize the super class init method
A common mistake is to write
self = [[super alloc] init];
which returns an instance of the superclass, which is NOT what you want in a subclass constructor/init. You get back an object that does not respond to the subclass methods, which can be confusing, and generate confusing errors about not reponding to methods or identifiers not found, etc.
self = [super init]
is needed if the super class has members (variables or other objects) to initialize first before setting up the subclasses' members. Otherwise the objc runtime initializes them all to 0 or to nil. (unlike ANSI C, which often allocates chunks of memory without clearing them at all)
And yes, base class initialization can fail because of out-of-memory errors, missing components, resource acquisition failures, etc. so a check for nil is wise, and takes less than a few milliseconds.

- 1,920
- 14
- 26