self.variableName与_variableName与@sysnthesize variableName [英] self.variableName vs. _variableName vs. @sysnthesize variableName
问题描述
Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?
注意:对于那些想了解这一点的人们，我想出了我困惑的根源.在.h中，我有:
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;
...
这导致self.variableName和_variableName是.m中的两个不同变量.我需要的是:
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;
...
然后，在类'.m中，self.variableName和_variableName是等效的
Then, in the class' .m, self.variableName and _variableName are equivalent
在带有ARC且针对iOS 5.0+项目的全新Xcode 4.5+中，与旧样式相比，使用_variableName相对于self.variableName有明显的优势(运行时效率，速度等) @synthesize variableName?
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?
我的理解是Xcode 4.5+将创建一个与self.variableName等效的默认访问器_variableName，并且不使用@synthesize variableName的唯一原因是为了避免iVars与传入变量之间的混淆，对吗?
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?
对我来说，仅使用self.variableName来访问iVar似乎对于您要查找的变量最直接，最清楚.除了键入_与self.之外，使用_variableName是否有优势?
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?
推荐答案
我的理解是Xcode 4.5+将创建一个与self.variableName等效的默认访问器"_variableName"，并且不使用"@synthesize variableName"的唯一原因是为了避免iVars与传入变量之间的混淆，正确?
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?
在这种情况下，_variableName不是访问器，它是由编译器自动生成并在自动@synthesize的setter和getter中使用的ivar.通常，最好是尽可能使用访问器(即self.variableName)，以便键值观察和绑定之类的东西对该属性起作用.
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.
直接访问ivar时，可以通过直接内存访问来访问它，就像访问结构中的数据一样.它只是获取拥有ivar的对象的指针，偏移内存地址，并尝试在该位置读取或写入内存.使用点表示法(self.variableName)调用访问器方法来设置或获取该属性，并且可以在此过程中做很多不同的事情，例如:
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)锁定:如果该属性将在多个线程中使用并且是atomic属性，则运行时将自动进行一些锁定以确保不会在以下位置访问该属性同时来自多个线程.如果您的对象不打算在多个线程上使用，则可以在属性声明中提供nonatomic提示，以便综合访问器跳过锁定.
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)键值通知:属性的默认设置器调用-willChangeValueForKey:和-didChangeValueForKey:，它们在属性更改时发出通知.如果使用绑定，则任何东西都要正确更新，对于任何其他键值观察来说，这都是必需的.
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)自定义访问者行为:如果最终编写了自己的设置器和获取器，则说明了您在其中实现的任何自定义内容.
3) Custom accessor behavior: If you end up writing your own setters and getters, any custom stuff that you implement within those.
从技术上讲，直接访问ivar的速度比使用访问器的速度快，但是在极少数情况下，它会显着影响性能，并且可能是过早优化的情况.即使您不希望立即使用上面列出的好处，还是最好使用访问器，这样一来，如果您以后决定需要某些功能，则不必更改每个实例访问该变量的信息(并且可能会在此过程中创建意外的新错误).
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).
此外，如果您直接访问ivars并最终将您的类重构为类别或子类，则它会变得混乱，因为您通常必须将ivar声明为@protected变量.如果您使用的是访问器，则不必这样做.
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.
通常，我尝试仅直接在init，dealloc和属性的访问器中访问ivars.许多工程师都遵循此经验法则，因为有时在对象init'或dealloc'ing时，访问器中发生的自定义内容可能导致意外行为.例如，如果访问器中的任何内容导致对象retain或release甚至对对象形成归零弱引用，则在dealloc中使用它会导致崩溃.
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.
这篇关于self.variableName与_variableName与@sysnthesize variableName的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
