PDA

View Full Version : Macro- lValue error




mpramodjain
Jun 4, 2011, 04:15 AM
Hi,

I have been using, the following macro, for releasing the objects

#define RELEASE_NIL(object) if(nil!=object){[object release]; object=nil; }

But when I use this macro for releasing a class object(SubClass of NSObject), following are my responses..



RELEASE_NIL(mAppDelegate_.myObject); - No Error
RELEASE_NIL([mAppDelegate_ myObject]); - error: lvalue required as left operand of assignment

Do anyone know, whats the problem with the second way throwing error and what it is expecting..????



robbieduncan
Jun 4, 2011, 05:28 AM
Hi,

I have been using, the following macro, for releasing the objects

#define RELEASE_NIL(object) if(nil!=object){[object release]; object=nil; }

But when I use this macro for releasing a class object(SubClass of NSObject), following are my responses..



RELEASE_NIL(mAppDelegate_.myObject); - No Error
RELEASE_NIL([mAppDelegate_ myObject]); - error: lvalue required as left operand of assignment

Do anyone know, whats the problem with the second way throwing error and what it is expecting..????

Macros work a simple text replacement. So in the second case you get


if(nil!=[mAppDelegate_ myObject]){[[mAppDelegate_ myObject] release]; [mAppDelegate_ myObject]=nil;


The final statement is clearly illegal. You cannot set the value in this way. The reason it works in the first case is down to the way the syntactic sugar of properties works. Properties are basically a clever/case sensitive text expansion to the getter/setter methods. The first case, after macro expansion looks like:


if(nil!=mAppDelegate_.myObject){[mAppDelegate_.myObject release]; mAppDelegate_.myObject=nil;


After the syntactic sugar of the properties is expanded we get:


if(nil!=[mAppDelegate_ myObject]){[[mAppDelegate_ myObject] release]; [mAppDelegate_ setMyObject:nil];


Note how the replacement is clever: it knows when to use the set accessor. This is the key difference.

I would note that releasing an object owned by another class in this way is in contravention of the normal Cocoa memory management rules and I would recommend against it.

mpramodjain
Jun 5, 2011, 09:24 AM
Note how the replacement is clever: it knows when to use the set accessor. This is the key difference.



Thanks for the reply. It was my insane, not to think any long on this.


I would note that releasing an object owned by another class in this way is in contravention of the normal Cocoa memory management rules and I would recommend against it.

Can you please make it more clear, how it is contravention of the normal Cocoa memory management, as per my little knowledge, the preprocessor just replaces the passed argument..

robbieduncan
Jun 5, 2011, 10:40 AM
Can you please make it more clear, how it is contravention of the normal Cocoa memory management, as per my little knowledge, the preprocessor just replaces the passed argument..

You should have read, and understood, all of The Cocoa Memory Management Guide (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html) before writing any code, in particular the Memory Management Rules (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html%23//apple_ref/doc/uid/20000994-BAJHFBGH). These state


You only release or autorelease objects you own.
You take ownership of an object if you create it using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message.


You are not taking ownership of the object but you are releasing it.