I know that you use #synthesize to create setter and getter methods, which makes things easier because then you don't have to write your own.
There are certain places where you have to use self.property instead of just property in order to make use of the setter and getter methods, such as in dealloc and initWithCoder.
This tells me that these setter and getter methods are doing something else that's important, besides making it easier for you to set and get a variable. What are they doing and how do they do it?
They're doing whatever you told them to do in the #property statement or your own implementation, if you chose to write one. Most often, the reason for using the accessors rather than directly modifying instance variables is to avoid memory leaks. Imagine an NSString instance variable declared with
#property (nonatomic, retain) NSString *myString;
#synthesize myString;
These lines generate an accessor that correctly calls release and retain when you want to change the myString property of an object. If you didn't call the accessor, you could potentially leak the old value, unless you were careful to do the memory management yourself.
Your base precept:
There are certain places where you have to use self.property instead of
just property in order to make use of the setter and getter methods, such as
in dealloc and initWithCoder.
This tells me that these setter and getter methods are doing something
else that's important...
isn't quite correct. The difference here is that using self.propertyname specifically invokes the getter/setter when used within that class, where directly using propertyname doesn't - it accesses the instance variables directly.
Per #Carl Good practice is that you use the getter/setter sequence everywhere you absolutely can, as that keeps you pretty safe from missing a corner case of memory management.
I second what #heckj and #Carl said, but must add one more point.
In general it is not safe to use accessors in either init or dealloc. The problem is that you class might be subclassed, the accessors might be overridden. Then these accessors might access other properties of your class or a subclass. This might lead to crashes:
In the case of init these haven't been initialized yet (because in init the first call you do is [super init]).
In the case of dealloc these have already been freed (because in dealloc the last call you do is [super dealloc]).
In practice you may use accessors in init and dealloc. Under two premisses:
You know what you're doing. (see above)
You control all maybe inheriting code. (does not apply for frameworks, etc.)
Related
I am new in objective c and I have some doubts. I've seen that you can access to the properties of a class like var->myProperty and like that too variable.myProperty, but I do not know what the difference between the 2. I searched a lot in internet and really have not found a conclusive answer.
Sorry if I have spelling errors, thanks in advance.
There are three cases to consider:
use of someObject.something
use of self->something
use of otherObject->something
someObject.something is the dot syntax. It is exactly equivalent to [someObject something] in terms of behavior. It is a method call. Note that something does not have to be declared via an #property. That is, someArray.count or someString.length are both syntactically valid.
self->something is accessing an ivar directly. It is a very rarely used syntax; rare is in pretty much never. Instead, just access the ivar directly using something = or [something doSomething]. No need for the ->.
otherObject->something is grubbing around otherObject's instance variables directly. Bad programmer. No donut. Don't do that. It breaks encapsulation and leads to extremely fragile, hard to maintain, code.
A note on #property declarations. If you have:
#property (atomic, strong, readonly) SomeClass *foo;
And if you let the compiler automatically #synthesize everything, it will create an instance variable named _foo.
You should use direct access in your init and dealloc methods, but -- typically, though not always -- use the setter/getter everywhere else. I.e. in your init you would do _foo = [SomeClass someClassWithSomeMagicValue:42] (assumes ARC, so no retain needed). Everywhere else, you would do [[self foo] castMagic];.
The obj->foo syntax accesses the ivar foo of obj whereas obj.foo accesses the property (defined by #property). The main difference is that obj->foo does not use any getters/setters and writes to the ivar directly.
For example, if you defined the property like this
#property (atomic, strong, readonly) SomeClass *foo;
Modern Objective-C compilers will automatically create an ivar _foo and the property foo for you (without the need of declaring the ivar and #synthesizeing the property.
obj.foo will then automatically use the atomic getter and will make the property readonly (ie no setter). Using the ivar syntax obj->_foo, you are reading the property non-atomically(!) and you can even write it (remember, the property is readonly!).
Usually it's very easy: Always use the property syntax, except in init and dealloc, there you use the ivar syntax. Obviously when you are actually implementing a getter or a setter yourself, that's another place to use the ivar syntax. (thanks to #godel9). (Remember: That's a rough guideline, there are other use-cases where you might want direct ivar access).
EDIT: Because of some critique in the comments: It's true that the dot syntax can also be used without declaring something as #property, eg some use array.count instead of [array count] (for NSArray *array). But given that the OP asked about properties vs ivars, that was certainly not asked. Also note that for a given #property ... SomeClass *foo the ivar is not necessarily _foo but that's would be the auto-generated ivar name in recent ObjC compilers (with #synthesize you can map properties to arbitrary ivars).
look at Pointers in objective-c
http://www.drdobbs.com/mobile/pointers-in-objective-c/225700236
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?
Note: For the folks digging around trying to understand this, I figured-out the source of my confusion. In the .h, I had:
...
#interface myClass : parentClass {
className *variableName:
}
#property (strong, nonatomic) className *variableName;
...
This leads to self.variableName and _variableName being two distinct variables in the .m. What I needed was:
...
#interface myClass : parentClass {
className *_variableName:
}
#property (strong, nonatomic) className *variableName;
...
Then, in the class' .m, self.variableName and _variableName are equivalent
In brand-new, Xcode 4.5+, with ARC, targeting iOS 5.0+ project, is there a distinct advantage (runtime efficiency, speed, etc.) to using _variableName over self.variableName vs. the old-style #synthesize variableName?
My understanding is that Xcode 4.5+ will create a default accessor _variableName that is equivalent to self.variableName and the only reasons not to use #synthesize variableName is to avoid confusion between iVars and passed-in variables, correct?
To me, just using self.variableName to access an iVar seems the most straightforward and clear as to which variable you're looking for. Other than typing _ vs. self., is there an advantage to using _variableName?
My understanding is that Xcode 4.5+ will create a default accessor "_variableName" that is equivalent to self.variableName and the only reasons not to use "#synthesize variableName" is to avoid confusion between iVars and passed-in variables, correct?
In this case, _variableName isn't the accessor, it's an ivar that is automatically generated by the compiler and used in the automatically #synthesized setters and getters. Generally, it is considered best to use accessors whenever possible (i.e. self.variableName) so that things like key-value observation and bindings work for that property.
When you access an ivar directly, it is accessed via direct memory access, the same way you would access data in a struct. It simply takes the pointer for the object that owns the ivar, offsets the memory address and attempts to read or write to the memory at that location. Using dot notation (self.variableName) calls the accessor methods to set or get that property and can do a number of different things along the way, such as:
1) Locking: If the property is going to be used in multiple threads and is an atomic property, the runtime will automatically do some locking to make sure that the property is not accessed at the same time from multiple threads. If your object is not meant to be used on multiple threads, you can give the nonatomic hint in your property declaration so that the synthesized accessors skip the locking.
2) Key-Value Notifications: The default setters for properties call -willChangeValueForKey: and -didChangeValueForKey:, which sends out notifications when the property is changed. This is necessary for anything to update properly if bindings are used, and for any other key-value observation.
3) Custom accessor behavior: If you end up writing your own setters and getters, any custom stuff that you implement within those.
Technically, accessing the ivar directly is faster than using accessors, but there are very few situations in which it will make a significant performance difference, and would probably be a case of premature optimization. Even if you don't feel like you would be using the benefits listed above right away, it's probably better to use the accessors anyway so that if you decide later on you need some of that functionality, you don't have to change every instance of accessing that variable (and possibly be creating unexpected new bugs in the process).
In addition, if you are accessing ivars directly and end up refactoring your class into categories or subclasses, it gets messy because you usually have to declare the ivar as a #protected variable. You wouldn't have to do this if you are using the accessors.
Generally, I try to only access the ivars directly in init, dealloc, and the property's accessor. A lot of engineers go by this rule of thumb because sometimes the custom stuff that happens in accessors can cause unexpected behavior while the object is init'ing or dealloc'ing. For example, if anything in the accessors causes something to retain or release your object or even form a zeroing weak reference to it, it will cause a crash if used in dealloc.
In the latest Xcode #synthesize is optional. By default, omitting #synthesize is the same as writing
#synthesize someName = _someName;
The only reason to use #synthesize is to rename the instance variable created to store the value of the property, for example
#synthesize someName = someSpecialName;
When you use self.variableName to access a variable, you go through a property, which is a short method that accesses the instance variable for you. Although the method dispatch is very fast, it may perform additional services for you, such as synchronizing the access to the variable (this is the case when you specify atomic or do not specify nonatomic in the property declaration). In cases like that, the access through self.variableName will be somewhat slower. If done in a tight loop, this could potentially make a difference. That is why you sometimes want to access the underlying instance variable directly by using _variableName.
So ... I'm still fairly new to Objective C ... taking some iTunes U corses ... doing some exercises and all ...
But when you uses to do #synthesize myProperty = _myIvarPropertyNameToUse; ... iOS 5 would create an ivar that would "back" the property.
What exactly is going on here as far as where things sit in memory ...
(1) Is the ivar a true variable? ... or is it a pointer to the location of the property in the object?
(2) The property is on the heap, (being part of the object), right? Is the ivar on the heap as well?
I think I may be losing the big picture ... what's the point of having a property backed by an ivar?
thanks,
An Objective-C object is just a C struct that is allocated on the heap (well, more or less). When you declare an instance variable (ivar), it is defined as an offset into that struct. So if you manually declared some ivars like this (don't do it this way anymore, but it illustrates the point):
#interface Foo : NSObject {
NSString *ivar1;
NSString *ivar2;
}
Then when you +alloc a new instance (call it foo), the struct will be some header followed by the ivars of NSObject followed by memory for ivar1 followed by memory for ivar2. ivar1 will be the foo point plus some offset. (This isn't exactly true anymore, but stay with me; it's simpler to understand the old implementation.)
Since foo is a pointer to a struct, you can actually refer directly to this offset pointer as foo->ivar1. It really is a struct. Never do this, but it is legal syntax.
Inside of the #implementation block, ivar1 is automatically translated to self->ivar1. Don't worry too much about how self is implemented, but trust that it's a pointer to your struct. Again, never use this -> syntax. It's an underlying implementation detail (and isn't always possible anymore; see below).
OK, so that's what an ivar is. In the old days (ObjC 1.0), that's actually all we had. You declared your ivars, and then you hand-created accessor methods that would set and return their values.
Then ObjC2 comes along, which in some cases also gave us something called the non-fragile ABI. That changes the underlying implementation of ivars somewhat, so you can't always actually use -> anymore. But you shouldn't have been using it anyway. Even so, it's simpler to pretend things are the old way. More to the point, ObjC2 added this new thing called "properties." A property is just a promise to implement certain methods. So when you say:
#property (nonatomic, readwrite, strong) NSString *property;
this is almost identical to saying the following:
- (NSString *)property;
- (void)setProperty:(NSString *)aProperty;
(The difference is very seldom important.) Note that this doesn't provide an implementation. It doesn't create ivars. It just declares some methods.
Now in ObjC1, we wrote the same accessor code over and over and over again. You had 20 writable ivars, you wrote 40 accessor methods. And they were almost identical. Lots of opportunities to mess up. And a lot of tedium. Thank goodness for Accessorizer.
With ObjC2, the compiler would give you the most common implementation for free if you added #synthesize. It would automatically make an ivar with the same name as the property, and write a getter and (if needed) setter to read and write that ivar. Passing =_property just changes the name of the ivar used. We call this the "backing ivar."
Now, in the latest version of the compiler, you don't even need #synthesize. This pattern is so insanely common, and has been for decades, that it is now the default unless you tell the compiler not to do it. And it automatically synthesizes an ivar with a leading underscore (which is best practice).
The one other piece of information you should know is that you should always use the accessor to access the ivar, even inside of the object. The only exceptions are in the init and dealloc methods. There you should directly access the ivar (using the leading underscore).
Just to be clear, when you do #synthesize myProperty = _myIvarPropertyNameToUse;, your only changing the name of the backing ivar. The line #synthesize myProperty; would also create a backing ivar, but it would be called myProperty, instead of _myIvarPropertyNameToUse...
The backing ivar is part of the object, so yes it's on the heap. It can be used as a true variable, meaning you can get and set it in the object code.
What is the difference between:
self.ivar;
self->ivar;
ivar;
Way of accessing ivar's in objective C.
When will the setter be invoked?
self->ivar and ivar access the instance variable directly. The accessor method is not called.
foo = self.ivar will call the [self ivar] accessor method (or the #property's getter= method if you specify it that way)
self.ivar = foo; wil call the [self setIvar:foo] access method (or the #property's setter= method).
In non-ARC environments, the both self->ivar, and ivar include no Objective-C calls, and instead set and get scalars from memory. The dot syntax, (e.g. self.ivar, or [self setIvar:]) makes an Objective-C call to a setter/getter method that can handle memory management, etc. Apple's #property includes #synthesize, which writes these method implementations for you.
In ARC environments, both properties and manually assigning an ivar include some memory management logic. It may even be that, in optimized ARC environments, the use of #property simply uses ARCs built-in logic, rather than making Objective-C calls whenever possible.
I have several years of experience in Obj-c and Cocoa, but am just now getting back into it and the advances of Obj-C 2.0 etc.
I'm trying to get my head around the modern runtime and declaring properties, etc. One thing that confuses me a bit is the ability in the modern runtime to have the iVars created implicitly. And of course this implies that in your code you should always be using self.property to access the value.
However, in init* and dealloc(assuming you're not using GC) methods we should be using the iVar directly (in the current runtime).
So questions are:
Should we use property accessors in init* and dealloc with Modern Runtime?
If so, why is this different? Is it just because the compiler can't see the iVar?
If I need to override an accessor, can I still access that iVar that will be defined at runtime or do I have to define an actual iVar that the runtime will then use?
Again, if I can access the synthesized iVar, why can't I continue to do this for the init* and dealloc methods?
I read the docs several times, but they seemed a bit vague about all of this and I want to be sure that I understand it well in order to decide how I want to continue coding.
Hope that my questions are clear.
Quick summary of testing:
If you don't declare the ivar in legacy, compiler is completely unhappy
If you use #ifndef __OBJC2__ around ivar in legacy compiler is happy and you can use both ivar directly and as property
In modern runtime, you can leave the ivar undefined and access as property
In modern runtime, trying to access ivar directly without declaration gives error during compile
#private declaration of ivar, of course, allows direct access to ivar, in both legacy and modern
Doesn't really give a clean way to go forward right now does it?
In the current (OS X 10.5/GCC 4.0.1) compiler, you cannot directly access the runtime-synthesized ivars. Greg Parker, one of the OS X runtime engineers put it this way on the cocoa-dev list (March 12, 2009):
You can't in the current compiler. A
future compiler should fix that. Use
explicit #private ivars in the
meantime. An #private ivar should not
be considered part of the contract -
that's what #private means, enforced
by compiler warnings and linker
errors.
And why isn't there a way to
explicitly declare instance variables
in the .m file for the new runtime?
Three reasons: (1) there are some
non-trivial design details to work
out, (2) compiler-engineer-hours are
limited, and (3) #private ivars are
generally good enough.
So, for now you must use dot-notation to access properties, even in init and dealloc. This goes against the best practice of using ivars directly in these cases, but there's no way around it. I find that the ease of using runtime-synthesized ivars (and the performance benefits) outweigh this in most cases. Where you do need to access the ivar directly, you can use a #private ivar as Greg Parker suggests (there's nothing that prevents you from mixing explicitly declared and runtime-synthesized ivars).
Update With OS X 10.6, the 64-bit runtime does allow direct access to the synthesized ivars via self->ivar.
Since instance variables themselves can only be synthesized in the modern runtime (and must be declared in the #interface under 32-bit or pre-Leopard), it's safest / most portable to also declare the ivar
Should we use property accessors in init* and dealloc with Modern Runtime?
My rule of thumb is "possibly" for -init*, and "usually not" for -dealloc.
When initializing an object, you want to make sure to properly copy/retain values for ivars. Unless the property's setter has some side effect that makes it inappropriate for initialization, definitely reuse the abstraction the property provides.
When deallocating an object, you want to release any ivar objects, but not store new ones. An easy way to do this is to set the property to nil (myObject.myIvar = nil), which basically calls [myObject setMyIvar:nil]. Since messages to nil are ignored, there is no danger in this. However, it's overkill when [myIvar release]; is usually all you need. In general, don't use the property (or directly, the setter) in situations where deallocation should behave differently than setting the variable.
I can understand eJames' argument against using property accessors in init/dealloc at all, but the flipside is that if you change the property behavior (for example, change from retain to copy, or just assign without retaining) and don't use it in init, or vice versa, the behavior can get out of sync too. If initializing and modifying an ivar should act the same, use the property accessor for both.
If so, why is this different? Is it just because the compiler can't see the ivar?
The modern runtime deals with class size and layout more intelligently, which is why you can change the layout of ivars without having to recompile subclasses. It is also able to infer the name and type of the ivar you want from the name and type of the corresponding property. The Objective-C 2.0 Runtime Programming Guide has more info, but again, I don't know how deeply the details explained there.
If I need to override an accessor, can I still access that iVar that will be defined at runtime or do I have to define an actual iVar that the runtime will then use?
I haven't tested this, but I believe you're allowed to access the named ivar in code, since it actually does have to be created. I'm not sure whether the compiler will complain, but I would guess that since it will let you synthesize the ivar without complaining, it is also smart enough to know about the synthesized ivar and let you refer to it by name.
Again, if I can access the synthesized iVar, why can't I continue to do this for the init* and dealloc methods?
You should be able to access the property and/or ivar anytime after the instance has been allocated.
There is another SO question with similar information, but it isn't quite a duplicate.
The bottom line, from the Objective-C 2.0 documentation, and quoted from Mark Bessey's answer is as follows:
There are differences in the behavior that depend on the runtime (see also “Runtime Differences”):
For the legacy runtimes, instance variables must already be declared in the #interface block. If an instance variable of the same name and compatible type as the property exists, it is used—otherwise, you get a compiler error.
For the modern runtimes, instance variables are synthesized as needed. If an instance variable of the same name already exists, it is used.
My understanding is as follows:
You should not use property accessors in init* and dealloc methods, for the same reasons that you should not use them in the legacy runtime: It leaves you open to potential errors if you later override the property methods, and end up doing something that shouldn't be done in init* or dealloc.
You should be able to both synthesize the ivar and override the property methods as follows:
#interface SomeClass
{
}
#property (assign) int someProperty;
#end
#implementation SomeClass
#synthesize someProperty; // this will synthesize the ivar
- (int)someProperty { NSLog(#"getter"); return someProperty; }
- (void)setSomeProperty:(int)newValue
{
NSLog(#"setter");
someProperty = newValue;
}
#end
Which leads me to think that you would be able to access the synthesized ivar in your init* and dealloc methods as well. The only gotcha I could think of is that the #synthesize line may have to come before the definitions of your init* and dealloc methods in the source file.
In the end, since having the ivars declared in the interface still works, that is still your safest bet.
I am running into the same problem. The way I am working around not being able to access the synthesized instance variables is the following:
public header
#interface MyObject:NSObject {
}
#property (retain) id instanceVar;
#property (retain) id customizedVar;
#end
private header / implementation
#interface MyObject()
#property (retain) id storedCustomizedVar;
#end
#implementation MyObject
#synthesize instanceVar, storedCustomizedVar;
#dynamic customizedVar;
- customizedVar {
if(!self.storedCustomizedVar) {
id newCustomizedVar;
//... do something
self.storedCustomizedVar= newCustomizedVar;
}
return self.storedCustomizedVar;
}
- (void) setCustomizedVar:aVar {
self.storedCustomizedVar=aVar;
}
#end
It's not that elegant, but at least it keeps my public header file clean.
If you use KVO you need to define customizedVar as dependent key of storedCustomizedVar.
I'm relatively new to Obj-C (but not to programming) and have also been confused by this topic.
The aspect that worries me is that it seems to be relatively easy to inadvertently use the iVar instead of the property. For example writing:
myProp = someObject;
instead of
self.myProp = someObject;
Admittedly this is "user" error, but it's still seems quite easy to do accidentally in some code, and for a retained or atomic property it could presumably lead to problems.
Ideally I'd prefer to be able to get the runtime to apply some pattern to the property name when generating any iVar. E.g. always prefix them with "_".
In practice at the moment I'm doing this manually - explicitly declaring my ivars, and deliberately giving them different names from the properties. I use an old-style 'm' prefix, so if my property is "myProp", my iVar will be "mMyProp". Then I use #synthesize myProp = mMyProp to associate the two.
This is a bit clumsy I admit, and a bit of extra typing, but it seems worth it to me to be able to disambiguate a little bit more clearly in the code. Of course I can still get it wrong and type mMyProp = someObject, but I'm hoping that the 'm' prefix will alert me to my error.
It would feel much nicer if I could just declare the property and let the compiler/runtime do the rest, but when I have lots of code my gut instinct tells me that I'll make mistakes that way if I still have to follow manual rules for init/dealloc.
Of course there are also plenty of other things I can also do wrong...