Is implementing autorelease code in constructor a good idea ?

Bracer · Oct 13, 2009

Code:

-(id) init
{
	if (self = [super init]) 
	{
	[self autorelease];
	return self;
	}
}

With all the memory dangers that hides behind the corner and with the knowledge that there are functions that returns autorelease objects like arrayWithCapacity or stringWithFormat, shouldn't it be a good idea to also implement autorelease in our own objects like this code illustrated above for when the pool drains, it will go as well and there is no need to pollute the main codes with layers of

Code:

[object autorelease]

.

wmprice1240 · Oct 13, 2009

Typically any well defined abstraction should not try and anticipate or make assumptions about the memory requirements for a particular client, platform, environment etc, and this includes the existence and scope of an autorelease pool.

At this point, your object has yet to be fully initialized so your essentially adding a partially initialized object to the autorelease pool which can have side effects. Similarly, Autorelease pools have a particular scope which is thread dependent. Embedding the autorelease knowledge into the initializer (note, the terms are different in Obj-C, there is no such thing as a 'constructor' in Obj-C) would make certain assumptions that might not be valid in all cases.

Obj-C has well defined semantics,idioms and usage patterns regarding object ownership and memory management.

You will want to read:

Mac Dev Center: Memory Management Programming Guide for Cocoa: Introduction

If code clarity is your concern you may want to consider using the garbage collector that is now a part of Objective-C 2.0 if your platform (the iPhone does not support the GC) permits its use.

ponhugste · Oct 25, 2009

Good post. I appreciate it.
Many thanks to ur post. I love it.

htvngoc2010 · Jan 6, 2010

wmprice1240 said:
Typically any well defined abstraction should not try and anticipate or make assumptions about the memory requirements for a particular client, platform, environment etc, and this includes the existence and scope of an autorelease pool.

At this point, your object has yet to be fully initialized so your essentially adding a partially initialized object to the autorelease pool which can have side effects. Similarly, Autorelease pools have a particular scope which is thread dependent. Embedding the autorelease knowledge into the initializer (note, the terms are different in Obj-C, there is no such thing as a 'constructor' in Obj-C) would make certain assumptions that might not be valid in all cases.

Obj-C has well defined semantics,idioms and usage patterns regarding object ownership and memory management.

You will want to read:

Mac Dev Center: Memory Management Programming Guide for Cocoa: Introduction

If code clarity is your concern you may want to consider using the garbage collector that is now a part of Objective-C 2.0 if your platform (the iPhone does not support the GC) permits its use.

^^ good point. Glad I joined this forum already

Is implementing autorelease code in constructor a good idea ?

Bracer

wmprice1240

ponhugste

htvngoc2010

Shop Amazon