I have question when I override setter for a #property.
that is:
If I set a property like this :
#property (strong) NSString *name;
In 'MRC' it will auto-generate getter and setter, assume setter will implement like this :
- (void)setName:(NSString *)name
{
[_name release]; // Release previous.
_name = name;
[_name retain]; // Remain object.
}
When I override setter in 'MRC', I can manage object by follow 'strong' behavior like code above,
but when in 'ARC', what will setter implement like or how to manage object to make it behavior like 'strong' since it has no 'retain and release' in 'ARC' ?
Thanks for yor time!
Under ARC, the compiler generates this setter:
- (void)setName:(NSString *)name {
_name = name;
}
But since _name is declared __strong (because the property is strong), the assignment turns into a call to objc_storeStrong:
- (void)setName:(NSString *)name {
objc_storeStrong(&_name, name);
}
The objc_storeStrong function takes care of the retain and release, and does so more safely than yours:
id objc_storeStrong(id *object, id value) {
value = [value retain];
id oldValue = *object;
*object = value;
[oldValue release];
return value;
}
(Consider what happens in your setter if name == _name and its retain count is 1 at the start of the setter. The objc_storeStrong function is also carefully written to avoid race conditions when multiple threads try to set the property simultaneously.)
ARC doesn't really require that you do anything special or additional, except for explicit bridging to Core Foundation pointers (which the compiler can auto-fix). It mainly requires that you don't write memory management code (like retain/release calls) yourself. You really don't need to "learn ARC", you only need to learn the memory issues that ARC cannot handle for you, like retain cycles (bad) and the management of C pointers (i.e. Core Foundation types--except when called from Swift, in which case ARC can handle them as well). The whole point of ARC is automating a part of software development that is very tedious and error-prone; it's less for you to worry about, not more. As an analogy, you don't really need to know anything about SQL in order to use Core Data...the finer details are abstracted away for you.
You made the property strong by virtue of declaring it strong, there isn't anything special you have to do in the setter:
-(void)setName:(NSString*)name
{
_name = name;
}
Of course, that is a silly example because there is no reason to override a setter when all you're doing is the default behavior, anyway. But you get the point...
Related
Can someone please explain to me (in simple terms) why an instancetype is used in Objective-C?
- (instancetype) init {
self = [super init];
if (self) {
// Custom initialization
}
return self;
}
It's to increase type safety.
Back in the old days, initialisers just returned an object of type id (any object).
With normal initialisers (those that begin with "init", "alloc" or "new"), this wasn't usually a problem. The compiler would automatically infer the type that it returned and therefore restrict any method calls on the object to the instance methods of that class.
However, this was a problem with static convenience initialisers or "factory methods" that didn't necessarily follow the same naming convention - therefore it was unable to apply the same type safety.
This means that with a class like this:
#interface Foo : NSObject
+(id) aConvenienceInit;
#end
The compiler would accept code like this:
NSArray* subviews = [Foo aConvenienceInit].subviews;
Why? Because the returned object could be any object, so if you try and access a UIView property - there's no type safety to stop you.
However, now with instancetype, the result you get back is of type of your given instance. Now with this code:
#interface Foo : NSObject
+(instancetype) aConvenienceInit;
#end
...
NSArray* subviews = [Foo aConvenienceInit].subviews;
You'll get a compiler warning saying that the property subviews is not a member of Foo*:
Although it's worth noting that the compiler will automatically convert the return type from id to instancetype if your method begins with "alloc", "init" or "new" - but nonetheless using instancetype wherever you can is a good habit to get into.
See the Apple docs on instancetype for more info.
Imagine two classes:
#interface A : NSObject
- (instancetype)init;
#end
#interface B : A
#end
The init method from A is inherited to B. However, in both classes the method has a different return type. In A the return type is A and in B the return type is B.
There is no other way to declare the return type for initializers correctly. Note that most programming languages with classes don't even have return types for constructors, therefore they completely avoid the issue.
This is the reason why Obj-C needs instancetype but of course it can be used outside initializers, too.
It is important to use instancetype instead of id in Objective-C if you are also using this code in Swift. Consider the following class declaration:
#interface MyObject : NSObject
+ (id)createMyObject;
- (void)f;
#end
If you want to create a MyObject instance in Swift 5.3 with createMyObject and then call f for this object, you will have to do the following:
let a = MyObject.createMyObject()
(a as? MyObject)?.f()
Now replace id with instancetype in MyObject to have the following Swift code:
let a = MyObject.create()
a?.f()
As you can see now, you can use MyObject.create() instead of MyObject.createMyObject(). And you don't need to use (a as? MyObject) since a is defined as MyObject? and not as Any.
After updating to Xcode 6 many incompatible conversion assignment warnings / errors started to appeared
In the .h file:
#property (nonatomic) BOOL *done;
In the .m file:
#synthesize done;
- (id)init
{
if (self = [super init])
{
self.done = FALSE;
}
return self;
}
- (void) crashed {
self.done = TRUE; #this line gives an incompatible type conversion warning
}
Lots of these warnings appeared after the upgrade. Does anyone share similar problem?
This is not a localized problem, the issue spread across the entire project.
I thought some of my foundation was wrong, or is it ?
Not all variables in Objective C have to be declared with the * character as some newcomers to the language think. It is C legacy to show that the variable is a pointer to an object. Some basic types like int and BOOL are too simple to require the overhead of storing them in an object, so C-style primitive types are used. From the docs:
Scalar types are used in situations where you just don’t need the
benefits (or associated overheads) of using an object to
represent a value. While strings of characters are usually represented
as instances of the NSString class, numeric values are often stored in
scalar local variables or properties.
BOOL is a primitive data type in Objective C and is not supposed to be a pointer. The warnings are correct. Declare the variable like this:
#property (nonatomic) BOOL done;
Note the lack of the * character next to the variable name. Other primitive types like int or float also should be declared in a similar fashion.
Some other things about your code. The correct Objective C convention for BOOL values is YES instead of TRUE and NO instead of FALSE, so you should stick to it. Also, since Xcode 4.4, you don't need #synthesize outside of a few special cases described here. As pointed out in the comments, it's also better to use instancetype instead of id in your case as described in the docs.
I'm pretty sure you want to do it this way:
Header file
#property (nonatomic) BOOL done; // Note: NOT a pointer
Implementation file
- (instancetype)init {
if (self = [super init]) {
self.done = NO;
}
return self;
}
- (void)crashed {
self.done = YES;
}
I know the instance variable in ARC are by default __strong. How can I release an instance variable when the containing class is still retained. In the following example v is __strong
and c is allocated when object of A is created some where and retained. I want to release the
c instance variable. How to should I do that?, What should be in releaseC method that will release the c instance variable.
#interface A {
Obj *c;
}
#implementation A {
- (id)init {
if((self = [super init])){
c = [[Obj alloc] init];
}
return self;
}
- (void)releaseC {
//what should be here?
}
}
Obj *c; = [[Obj alloc] init];
- (void)releaseC {
c = nil;
}
You cannot directly control when an object is released BUT you can indirectly cause it to happen. How? Remember what ARC does EXACTLY. Unlike human coding convention, ARC parses your code and inserts release statements AS SOON AS OBJECTS CAN be released. This frees up the memory for new allocations straight away, which is awesome/necessary. Meaning, setting an object to nil, or simply allowing a variable to go out of scope ... something that CAUSES A 0 RETAIN COUNT forces ARC to place its release calls there. It must ... because it would leak otherwise.
- (void)releaseC {
c = nil;
}
c = nil;
But some would argue it isn't productive from an efficiency standpoint. And while the release will be immediate in the sense it isn't any longer usable, the memory may not be freed immediately.
there is no need to release the variable in ARC. it done automatically
You are probably miss understanding what you want to do. I suppose you want to release the variable for memory issues. All you have to do is nil it. Instance variables are pointers to objects. As long as an object is pointed by something it is kept alive. As soon as you dont need something you can "stop pointing at it" and it will be released automagically.
As for the design, I am not so sure why you would have a public method that releases an instance variable. (I'm assuming its public because if it was not you would just nil it without actually having to write a method). If you do indeed intend to be able to release an instance variable from outside the class, I would simply make the Instance variable public and release it from anywhere setting it as nil.
I've linked a button to the following method:
- (IBAction)searchButton
{
NSString *searchText = _searchField.text;
NSLog(#"lol");
[_search testSearch:searchText];
}
The last line calls the method testSearch within an object named search, defined as follows:
#property (strong, nonatomic) Search *search;
Within Search, testSearch is defined as follows:
-(void)testSearch:(NSString *)testString
{
NSLog(#"HELLO");
}
My final output, when I click search, is only "lol" (each time I click the button). It does NOT print "HELLO", as testSearch should be doing. I have included testSearch in Search.h, so it should be accessible...why isn't this method being called?
You should start by initializing your _search ivar to an instance of Search in your designated initializer (or in viewDidLoad or some other "user gonna use this" method).
- init {
if ((self = [super init])) {
_search = [[Search alloc] init];
}
return self;
}
You should generally avoid lazy initialization in getter methods for a variety of reasons:
It adds unnecessary code; use #property and the default synthesized implementations. Leads to simpler code and less of it.
a getter that does lazy initialization yields a getter that causes mutation. That is inconsistent it is quite odd to see a KVO change notification when calling a getter (unless, of course, you don't fire the KVO notification... at which point, you have non-observeable mutation).
a getter that causes mutation is inherently not thread safe unless you add the code, tricky code, to make it so.
lazy initialization is generally a premature optimization. Unless you have an identifiable memory or CPU performance issue caused by initializing a resource "too soon", then adding the complexity of lazy initialization is wasted effort.
lazy initialization can lead to weird ordering dependencies and other complexities. Far better to have a known entry point for initializing a subsystem than to rely on subsystem X being initialized prior to Y, both by side effect.
The search object you are sending the message to has not been instantiated so you are sending a message to nil. In Obj-C this does not crash the program, instead it does nothing. Its a best practice in Objective-C programming to perform lazy instantiation in the getter method of the iVar. Additionally, you would have to couple this best practice with not accessing your iVars directly and use the setters and getters for whichever iVar you are trying to access. Below is an example of lazy instantiation in the getter method for your search iVar:
-(Search *)search
{
if(!_search){
_search = [[Search alloc]init];
}
return _search;
}
Here is your method call while NOT accessing the iVar directly:
[search testSearch:searchText];
I have a situation where troops can attack buildings. Each troop keeps a pointer to its target.
#property (nonatomic, weak) Building *target;
In an update loop, the troops periodically cause damage to their target.
if (_target)
{
if (/*enough time has passed since last attack, attack again*/)
{
[_target attack];
if (_target.health <= 0)
{
[_target removeFromParentAndCleanup:YES]; //Cocos2d
_target = nil;
}
}
}
else /* Find new target */
The problem is:
troop1 deals the blow that fells building1 and moves on to building2
troop2 was attacking building1 but waits until its next attack to determine that building1 is now nil.
I realise the problem is that troop2's pointer has not been set to nil and instead I should be checking that the value of the pointer is nil.
I tried using if (*_target) but was met with the message
Statement requires expression of scalar type
If there a way to achieve this kind of comparison in Objective-C? What other options are there for determining when a value has changed? KVO? Some extensive delegate pattern?
It is the pointer itself that is set to nil when the object it points to is deallocated. if (objectPointer == nil) is always the way to check if an object is nil in Objective-C/Cocoa. If the pointer is not nil, it means the object in question has not in fact been deallocated. If you dereference a pointer to an object, you get a struct, hence the compiler error about needing a scalar value in the if expression.
So, in your case, if if(self.target != nil) is not giving you the result you expect, you should look for remaining strong references to the target (from other objects).
More broadly, as hinted at by trojanfoe's answer, you're relying on ARC's zeroing weak reference behavior for real program logic. In theory this is OK, as (contrary to his initial statement), ARC's zeroing weak behavior is reliable/deterministic. But, it does mean that you have to ensure that targets are always deallocated when they're no longer on the playing field (or whatever). This is a bit fragile. Zeroing weak references are intended as a way to avoid retain cycles (essentially a form of memory leak), rather than as a way to implement logic the way you're doing. The gist of trojanfoe's solution, where you explicitly register and unregister targets as necessary, is probably a more robust solution.
There may be something that I have overlooked here, but to check if the target2 property is nil, just do:
if ( self.target2 == nil ) {
// Something
}
I think you are relying too heavily on the implementation of ARC in that you only know if an object has been removed if the pointer is nil. This is non-portable and can you make any guarantee between the object being released and the pointer becoming nil?
Instead, use a central dictionary of objects, mapped against their unique ID and store just this unique ID rather than the object pointer itself. In this example I'm using a NSNumber for the key using an incrementing integer, but there are probably better keys that can be used. Also Object is the base class of any object you want to store in this dictionary:
// Probably ivars in a singleton class
unsigned _uniqueId = 1;
NSMutableDictionary *_objects;
- (NSNumber *)addObject:(Object *)object
{
NSNumber *key = [NSNumber numberWithUnsignedInt:_uniqueId++];
[_objects setObject:object forKey:key];
return key;
}
- (void)removeObjectForKey:(NSNumber *)key
{
[_objects removeObjectForKey:key];
}
- (Object *)getObjectForKey:(NSNumber *)key
{
return [_objects objectForKey:key];
}
And in your target, simply store the building key:
#property (strong) NSNumber *buildingKey;
and get the building via the methods provided:
Building *building = (Building *)[objectDictionary objectForKey:buildingKey];
if (building != nil)
{
// building exists
}
else
{
// building does not exist; throw away the key
buildingKey = nil;
}
Since target is a weak reference, your code should work "as-is", assuming that [_target removeFromParentAndCleanup:YES]; removes all strong references to the target.
When the last strong reference is removed, all of the weak properties pointing to it will automatically be set to nil. If they are not automatically set to nil, then there is still a strong reference to the target somewhere.
Find and remove that reference, and this will work fine.