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?
It is not fully clear to me (other than for readability of the code), why you wanna create an internal variable with an underscore prefix when you create the property.
Since everything is handled internally, why bother to do so, since we do not add any code to the getter and setter?
And even if i gotta add some code to the getter or setter, i do not see why i cannot just do the check on myvar instead than having to check _myvar and then assign it to myvar.
Can anyone give me some explanation, other than "do it because that's what everyone does ?" I would like to understand the whole reason behind this practice (that seems to be pretty common even if there is no custom code for the getter and setter).
Thanks!
I've wondered this many times myself. Interested in other people's answer, but one reason I've found is that it forces you to notice if you're accessing the ivar directly when you should be using the getter/setter.
self.myvar = #"blah"; and _myvar = #"blah";
vs
self.myvar = #"blah"; and myvar = #"blah";
It's easy to leave the self. out by accident... it's a lot harder to put the _ in by accident.
An Objective-C property usually has a backing instance variable (I guess you know the difference between a property and an instance variable).
The property may have a different name than the instance variable.
For instance, you may have an instance variable named x, with a property named y.
You can synthesize the y property to the x variable using:
#synthesize y = x;
Now about the underscore.
It's a common practice to use an underscore prefix for instance variables, to prevent naming collisions, or compiler warnings (shadowed variable), when having for instance a method argument with the same name as an instance variable.
The underscore prefix also makes clear that you are referring to an instance variable.
By using the underscore prefix for instance variables, you're free to use the name without the underscore in method's arguments, stack variables, etc.
But when using a property, you usually don't want the user to write an underscore.
So you usually have an x property for an _x instance variable.
This is why you write:
#synthesize x = _x;
Let's take an example:
#interface Test: NSObject
{
int x;
}
#property( readonly ) int x;
#end
This is quite common... But now imagine this in the implementation:
- ( id )initWithX: ( int )x
{}
We have are a naming collision.
Inside our method, x will refer to the method's argument. And there is no pretty way to access the x instance variable.
Depending on your compiler's warning flags, this may also generate a warning (-Wshadow).
If you use an underscore prefix for your instance variable, everything is just simple:
- ( id )initWithX: ( int )x
{
if( ( self = [ super init ] ) )
{
_x = x;
}
return self;
}
No conflict, no naming collision, improved reading... Just a nice way...
When using a property of self, it's easy to forget the "self":
[self.field doSomething]; // what you probably want
[self setField:someObject]; // also kosher
self.field = someObject; // ditto, although not my style
vs.
[field doSomething] // might work.. but will bite you eventually
field = someObject; // almost certainly wrong anywhere outside a custom setter
If the property and the ivar are named identically, the latter cases will compile without complaint and appear to work... until they don't, and you get a weird hard-to-reproduce edge case bug.
If the ivar has a slightly different name, say with a trailing _ appended, the compiler will stop you and make you explicitly decide: do I want to refer to the property here, or the ivar directly?
(All that said, I am lazy and often do #synthesize field;, and replace it later with #synthesize field = field_; when I actually need the distinct ivar, say when it's custom-setter-writing time.)
Related
I understand this is probably bad practice, but I was just curious as to whether or not this has any negative side-effects, in Objective-C (trying to learn as much as I can):
#interface MyClass ()
// Declare a string called 'foo'
#property (nonatomic, strong) NSString *foo
#end
#implementation MyClass
...
- (void)modifyFoo {
// Create a local variable with the same name as a property
NSString *foo = #"Hello!" // No compiler warnings?
self.foo = foo; // <---- Is this OK?
}
This will not throw up a warning in the compiler, and sure enough, my code works as normal. If there are zero negative side-effects, does the type of property, e.g. weak/strong/assign, etc, have an influence on whether or not this is OK?
Note: I am aware that this will not work when the property is synthesised.
This is fine and is my personally preferred approach. The reason no compiler warning is generated is that the instance variable is actually named _foo. This is done by the auto-synthesise added by the compiler (it generates #synthesize foo = _foo for you). Maintaining naming consistency aids clarity.
The main potential side effect is that you inadvertently add / fail to add self. and end up trying to message nil.
Firstly:
this will not work when the property is synthesised.
Huh? Why not?
Actually, it's "OK" in the sense that it works. Actually, there's no ambiguity when you use the self keyword and the dot notation to access your property. If, however, you had an instance variable with the same name as your local variable, then the object with a narrower scope (the local variable in this case) hides the one with a wider scope (the ivar). And that may be undesirable. As far as I know, it even results in a compiler warning. Furthermore, it's hard to get it wrong and decreases overall code readability, so don't do this if you have that identically named instance variable.
If I recall correctly, recent versions of the clang/LLVM toolchain automatically synthesize properties for you, and the name of the backing ivar for a property is preceded by a leading underscore, so this should not be a problem.
Sometimes we may explicitly specify the name of an instance variable in the synthesize statement, e.g.,
In SomeViewController.h,
//....
#property (nonatomic, retain) NSObject *variable;
//....
In SomeViewController.m,
//....
#synthesize variable = _variable;
//....
But why bother making this extra effort if the instance variable will be implicitly named as _variable even if we simply put it as:
#synthesize variable;
in the SomeViewController.m.
Can anyone share some idea on why it is necessary? Thank you :D
Just to avoid confusion (see comments): Using the = _variable part of the #synthesize is not required, nor is the #synthesize itself required any more.
This effort is only requied, when you want to link the property to a specific instance variable. With earlier Objective-C versions this part of the statement was required to set the name to something different from the property name, so when you want to call the iVar _variable and the property variable. The default would be variable (unlike your question). Without that = something ivar and property have the same name.
BTW, there is nothing wrong with using the same name for both. But having different names, a leading _ would do, makes it more clear to the programmer whether he/she accesses the ivar directly or though the accessor methods. Sometimes this is of vast importance, especially when not using ARC. Therefore it helps avoiding errors.
With current Objective-C, however, you could omit the #synthesize statement at all and go with the defaults in that case. The default automatically synthesized instance variable name would have a leading _ so _variable in your example.
Why in the newest version of Xcode (dp-4) are variables declared with retain,nonatomic made to use the underscore before the variable name? Does this create some sort of type safety?
For example, I create a property:
#property (retain, nonatomic) IBOutlet UILabel *name;
Unless I change the variable inside the dealloc to not have the _, I have to do:
#synthesize name = _name;
Why is this?
Mark Dalrymple, who's way smarter than I am, wrote a blog post at Big Nerd Ranch about this very subject. Bottom line: the underscore is a good idea. I will summarize his post here just in case the link stops working in the future, but if possible you should read his post instead of my summary.
He wrote this post back when explicitly calling #synthesize was mandatory. He advocated code such as:
// soapbubble.m
#synthesize viscosity = _viscosity;
#synthesize detergentBrand = _detergentBrand;
These days Xcode automatically and implicitly includes #synthesize. And it does so using the prepended underscore so apparently Apple's engineers agree with Mark.
His first reason is stylistic. It allows you to easily see which variables are local and which are arguments in a setter:
- (void) setPonyName: (NSString *) ponyName {
[_ponyName autorelease];
_ponyName = [ponyName copy];
}
(This is a pre-ARC setter, so now this method would be completely unnecessary, but if the setter did anything more involved than simply releasing and assigning a value it would still apply.)
His second reason (and the one I think is more important) is that eliminates a certain class of bug that can be very difficult to track down.
This code:
self.ponyName = #"Mikey";
is identical to:
[self setPonyName: #"Mikey"];
Without the prepended underscore, this code is also valid:
ponyName = #"Mikey";
but it doesn't call the setter so any side effects in the setter don't occur. Again, in a situation where the setter does extra work besides changing the local variable's value this can cause big headaches. With the prepended underscore, that line would cause a compile error. You would have to be very explicit about wanting to set a local variable:
_ponyName = #"Mikey";
and, being the conscientious programmer you are, you would include a comment explaining exactly why you are performing this irregular maneuver.
"_name" in your #synthesize name = _name, is just a variable name created automatically by your Xcode. This is done because #synthesize just creates setters and getters and if you don't use _name, it'll take your property name, i.e. name (in this case) and finally leads to bugs in your app. _name is just a naming convention. You can use any variable name in place of _name. So that #synthesize will use that variable name in its implementation.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Arrow operator (->) usage in C
Dot (“.”) operator and arrow (“->”) operator use in C vs. Objective-C
I'm a newbie looking at a freeware/open-source program last updated in 2008, and I don't recognize the -> in the following notation:
- (id)copyWithZone:(NSZone *)zone
{
GFIPGeniusItem * newItem = [[[self class] allocWithZone:zone] init];
newItem->_stringValue = [_stringValue copy];
newItem->_imageURL = [_imageURL copy];
newItem->_webResourceURL = [_webResourceURL copy];
newItem->_speakableStringValue = [_speakableStringValue copy];
newItem->_soundURL = [_soundURL copy];
return newItem;
}
I'm assuming it's allowing some sort of shortcut, but I'd love to specifically what it does.
It's a way to directly access an instance variable within an ObjC object from outside that object. (The syntax and -> is borrowed from C structs, behaving as if the reference were a pointer-to-structure).
This access mechanism is almost vestigial at this point, and very uncommonly seen in modern ObjC code, because good encapsulation requires the use of accessors and properties, not touching instance variables directly. It's legitimate in some very special cases, though, and this is one of them:
When copying an object, you want to get a resulting copy that matches exactly the state of the current self. The cleanest way of achieving this is often to set the copy's ivars explicitly, to prevent any side-effects that the init overloads or accessors might cause. It's "safe" because the code doing it is still located within the class that's in question, so if you needed to change or add ivars, you could update this code as well with the knowledge of anything else that might require.
Doing this from outside the class in question is bad form, and there's no good reason to do it.
In Objective-C you have some kind of two variable type accessors. The one everybody should know is the "." one (e.g. Class.variable). This type calls either the appropriate getter or setter.
Now, the other type - the one you asked for - is for in-class usage. Obviously, as the getter or setter gets called automatically with the "." notation you need a way to set the variable without a setter (calling the setter in the setter itself results in an endless loop). Therefore, this "->" notation is used -> simply, it is the direct-access mode.
Usually, Objective-C the variable name for both notations is the same but some prefer to have the in-class notation variable name beginning with "_". This is achieved by editing the #synthesize variable line to #synthesize variable = _variable.
That's a pointer indirection operator. a->b means the same thing as (*a).b (where the . is the structure member access operator, not Objective-C's property dot syntax).
When you say:
newItem->_stringValue
you're directly accessing the _stringValue instance variable of the object to which newItem points.
The -> operator is very common in C++, but not so much in Objective-C.
In Objective C, like in C++, the p->m notation is equivalent to (*p).m This is, the dereference of the pointer to the base type followed by a call to the corresponding method or property.
So in your case, using the other notation it would look like this:
(*newItem)._stringValue = [_stringValue copy];
(It's more common to use the -> operator)
By reading this post, It looks like certain rules should be considered when declaring global variables.
So I tried declaring global variables in the .m file. However, the code sense seems not happy to do this for me. For example, say I already have 2 lines in the .m file:
#implementation ViewController
#synthesize abc, xyz;
Now I want to add "BOOL isChecked;".
If I type this below "#synthesize" (or just between #implementation and #synthesize), the code sense actually suggests me to input "bool" (lower case) as I am typing "BOOL". If I type "BOOL" above "#implementation", it would suggest "BOOL" successfully.
Surely, the global variable is part of this class which means it should be inside the implementation. I am not sure why it doesn't like to let us do this.
This makes me feel that Objective-C doesn't like us to declare global variables below #synthesize. But my question is WHY? What I feel is that there may be a reason or Apple made a bug here.
Surely, the global variable is part of this class which means it should be inside the implementation. I am not sure why it doesn't like to let us do this.
Global variables aren't part of a class. Sure, you can put them inside an #implementation block, but they're really not a part of the class -- they're global -- so they don't really belong there.
Objective-C doesn't have class variables like Java or other languages do. You can fake them with global variables and class methods that access those variables, but at the end of the day, they're global, not specific to a class.
What the IDE's code sense help suggests is not an absolute indication of what the Objective C language "likes". Putting a global variable either outside or inside a class implementation generates equivalent compiled results from the Xcode Objective C compiler, and with no warnings.
However it might be considered better code style to put these declarations outside of the class implementation, as all global variables actually have global scope, not class scope.
In addition, you might want to assign an initial value to your global variables, instead of making any assumptions in your code of what that might be.
Objective-C does not have class variables. You declare a C global variable. This is how I do it:
Declare a static C variable. In your case:
static BOOL isChecked = NO;
Notice that I have initialized it. Notice that it is declared static, which restricts its visibility to the .m file it is declared in.
If you want a global object such as an array, you will need to initialize it:
static NSArray *myArray;
#implementation MyClass
+ (void)initialize {
if (self == [MyClass class]) {
myArray = [NSArray arrayWithObjects: ... ];
}
}
#end
Notice the if (self == [MyClass class]) check. +initialize will be called one or more times. Once when MyClass is used for the first time (e.g. call to +alloc). Possibly again when any subclass of MyClass is used for the first time. Hence the check to see if you are actually initializing MyClass, or a subclass of it.
And finally, if you want to access this variable outside of the code that it is declared in, create an accessor:
+ (BOOL)isChecked {
return isChecked;
}
Don't expose the global C variable by removing the static modifier. It makes it harder to debug, refactor or re-implement (what if isChecked suddenly depends on other state, how do you change this if it is directly used all over the place in other code?)