For example, there is a class
#interface Person: NSObject {
#property (weak) NSString *str;
#end
#implementation
- (void) init {
str = #"XYZ";
}
#end
Is it safe to declare all properties to weak to avoid reference count
overhead?
If not safe then why it's not safe?
What will be the reference count of str?
Is it safe to declare all properties to weak to avoid reference count overhead?
This is problematic on two counts. First, weak doesn't avoid reference counting. It actually performs more bookkeeping than strong. See Lots of overhead for weak property? for a good discussion of that.
Next, this is wrong because weak and strong mean different things that cannot be interchanged. As MartinM notes, if you make your properties weak, they'll just disappear as soon as you assign them if nothing else is holding onto them.
If not safe then why it's not safe?
It is totally safe. It just won't work. Your program will have well defined behavior, and shouldn't crash due to marking all your properties weak. Most of your properties will just be nil. If you used unsafe_unretained instead of weak, then you would avoid some reference counting overhead, and your program would typically crash (because the objects would still be destroyed, the pointers would just become invalid).
What will be the reference count of str?
That is not a meaningful question, even though it feels like one. In this particular case the answer is 9,223,372,036,854,775,807 because that's always the retain count of a static string, because static strings cannot be destroyed and ignore retain/release calls. (That value is NSNotFound in ObjC. I believe this used to return 1,152,921,504,606,846,975, but my tests indicate it's changed.)
But in the general case, it could be anything at this point in time. And what it is at this point in time versus at the end of the event loop (when the autoreleasepool drains) could be dramatically different. Do not chase retain count values. They will always lie to you. Create strong references to things you care about. Create weak references only when you need them for their specialized purposes.
Retain counts are an internal implementation detail. Before ARC, they were misleading to the point of uselessness. Since ARC, they're like asking "what assembly instructions will this compile to." It's important, but it depends on everything else about the program and how it's compiled.
If you have a specific performance problem related to memory management, then there are techniques for dealing with that in a case-by-case basis, and StackOverflow can help you. But ARC is extremely good at optimizing memory management. Let it do its job.
You should know which properties should be weak and which strong. It is a common practice declaring for example all IBOutlets as weak because they are being retained by the view that comes from the storyboard, so it is not necessary to keep a strong reference in the viewcontroller.
Another example would be a delegate that should always be weak, or it will prevent the delegate (mostly another viewcontroller) from being deallocated because the delegate's holder is still alive.
In your case, str will be nil after init, because there are no other references to its content. You should actually get a compiler warning if you do this.
Take a look at this thread with more detailed explanation: Weak and strong property setter attributes in Objective-C
Related
I have seen report that if a delegate uses assign instead of weak, the app crashes. Why?
Example: RestKit
With ARC a weak ivar will be automatically set to nil when the ivar object is deallocated. That means that if your delegate is destroyed and you try to message the delegate you'll just message nil, which has no effect. If the delegate ivar was merely assign then you would message some chunk of memory that no longer contained a valid object.
The only difference between assign and weak is that weak does extra work to avoid some common crashing bugs. The drawback, however, is that assign has much better performance than weak.
Specifically, when an object is released, any weak property pointing to it will be set to nil. Any assign property pointing to it will be left pointing at the object that is no-longer used.
And some other object is likely to be placed at the same location in memory as the old object, so suddenly instead of an instance of MyDelegate you might have a UIImage object in the same location in memory, or perhaps a float value, or anything at all.
So you should always use weak, for everything. But if you run into performance problems, check if weak is the cause, and consider switching to assign after learning how to avoid those crashing bugs.
For a delegate you should pretty much always use weak. Normally you'd only pick assign if you are dealing with millions of objects. Typically that doesn't happen with delegates.
Today I read book about ARC. So there are two type points both strong and weak points.
I already searched the property about them and got it.
But I couldn't see or understand why we use weak point instead of strong?
This is simple question. Please let me know easily.
Thanks.
First of all its not weak points, its weak property. Lets say if you don't want owner ship of a particular object you can use weak property. If the actual owner of this reference release this and its retain count becomes zero, a weak reference will be automatically assigned to nil. Which will save you from crashes.
You can get more information here : https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html
This question has been answered very well on apple's page !
I will just link it in hope it really helped you to get the required info !
link is here :) arc
also I think this SO question is very helpful for understanding the things :[link]here (Objective-C ARC: strong vs retain and weak vs assign)
To be simple, you use "weak property" and or "weak variable" for following:
You do not want to take the ownership of object. Like delegate/dataSource are generally declared weak.
You may say you can also use "assign" instead of "weak". When the variable is freed from memory, using "weak" automatically sets it to nil, whereas "assign" now is referring to deallocated instance and code can crash if you try to do something on it.
To avoid retain cycles causing memory leaks. For example avoid passing "self" in blocks. use "__weak id weakSelf = self", and now pass weakSelf in blocks.
ARC is your friend, but can do potential harm if not taken care of things mentioned above.
OK - newbie Objective-C question:
When declaring properties there are attributes such as below:
#property (weak, nonatomic)
I realize I need read up on this to fully understand it but most of what I found was reference material, so a link to a good article that could explain best practices / usage scenarios (when to use which attribute for primitives, reference types, outlets, etc) or a couple of examples would be appreciated.
Thanks!
Even though it is waaaay to late for an answer i've found this question while googleing the same issue and also found this article by apple which explains the whole thing perfectly.
Hope it helps to anyone who are researching the same thing,
http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html
From a recent class I gave on this (inspired by Paul Hegarty)
nonatomic - NOT thread safe see link Justin pointed out in the comments above.
strong (or retain) - keep this object allocated until I don’t point to it anymore (set it to nil). Compiler will also throw this out of the heap (deallocate it) if I am not pointed to strongly anymore (I get dealloc’d)
weak - keep this object allocated as long as something still points to it strongly. IBOutlets are usually declared as weak since they will be retained automatically by the view controller.
Primitive types are not allocated on the heap and don't use strong or weak
Atomicity has to do with threading, and is a pretty advanced topic for a newbie. The short answer, however, is that iOS properties are always declared as nonatomic. Here's some more detailed information about it.
The weak/strong keyword has to do with memory management with ARC and preventing what's called a retain cycle. This can also be a bit of a tough concept for a newbie, but the high-level overview is that a retain cycle happens when two objects have strong references to each other and thus neither object will be destroyed by ARC. This is a form of a memory leak, as you may have an object that's no longer in use but is still taking up memory. By declaring a property as weak, it will ensure that it's not automatically destroyed so long as something still has a strong reference to it. For instance, let's say you have an array with a couple of objects in it. Two of the objects have strong references to each other. Then, the array loses its owner and is destroyed. BUT, the two objects in that array that point to each other are NOT destroyed since they have strong references. Thus, you have two objects which you cannot access since the owning array is destroyed, but they're still taking up memory.
Can someone explain to me in detail when I must use each attribute: nonatomic, copy, strong, weak, and so on, for a declared property, and explain what each does? Some sort of example would be great also. I am using ARC.
Nonatomic
Nonatomic will not generate threadsafe routines thru #synthesize accessors. atomic will generate threadsafe accessors so atomic variables are threadsafe (can be accessed from multiple threads without botching of data)
Copy
copy is required when the object is mutable. Use this if you need the value of the object as it is at this moment, and you don't want that value to reflect any changes made by other owners of the object. You will need to release the object when you are finished with it because you are retaining the copy.
Assign
Assign is somewhat the opposite to copy. When calling the getter of an assign property, it returns a reference to the actual data. Typically you use this attribute when you have a property of primitive type (float, int, BOOL...)
Retain
retain is required when the attribute is a pointer to a reference counted object that was allocated on the heap. Allocation should look something like:
NSObject* obj = [[NSObject alloc] init]; // ref counted var
The setter generated by #synthesize will add a reference count to the object when it is copied so the underlying object is not autodestroyed if the original copy goes out of scope.
You will need to release the object when you are finished with it. #propertys using retain will increase the reference count and occupy memory in the autorelease pool.
Strong
strong is a replacement for the retain attribute, as part of Objective-C Automated Reference Counting (ARC). In non-ARC code it's just a synonym for retain.
This is a good website to learn about strong and weak for iOS 5.
http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1
Weak
weak is similar to strong except that it won't increase the reference count by 1. It does not become an owner of that object but just holds a reference to it. If the object's reference count drops to 0, even though you may still be pointing to it here, it will be deallocated from memory.
The above link contain both Good information regarding Weak and Strong.
nonatomic property means #synthesized methods are not going to be generated threadsafe -- but this is much faster than the atomic property since extra checks are eliminated.
strong is used with ARC and it basically helps you , by not having to worry about the retain count of an object. ARC automatically releases it for you when you are done with it.Using the keyword strong means that you own the object.
weak ownership means that you don't own it and it just keeps track of the object till the object it was assigned to stays , as soon as the second object is released it loses is value. For eg. obj.a=objectB; is used and a has weak property , than its value will only be valid till objectB remains in memory.
copy property is very well explained here
strong,weak,retain,copy,assign are mutually exclusive so you can't use them on one single object... read the "Declared Properties " section
hoping this helps you out a bit...
This link has the break down
http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.spelling.property
assign implies __unsafe_unretained ownership.
copy implies __strong ownership, as well as the usual behavior of copy
semantics on the setter.
retain implies __strong ownership.
strong implies __strong ownership.
unsafe_unretained implies __unsafe_unretained ownership.
weak implies __weak ownership.
Great answers!
One thing that I would like to clarify deeper is nonatomic/atomic.
The user should understand that this property - "atomicity" spreads only on the attribute's reference and not on it's contents.
I.e. atomic will guarantee the user atomicity for reading/setting the pointer and only the pointer to the attribute.
For example:
#interface MyClass: NSObject
#property (atomic, strong) NSDictionary *dict;
...
In this case it is guaranteed that the pointer to the dict will be read/set in the atomic manner by different threads.
BUT the dict itself (the dictionary dict pointing to) is still thread unsafe, i.e. all read/add operations to the dictionary are still thread unsafe.
If you need thread safe collection you either have bad architecture (more often) OR real requirement (more rare).
If it is "real requirement" - you should either find good&tested thread safe collection component OR be prepared for trials and tribulations writing your own one.
It latter case look at "lock-free", "wait-free" paradigms. Looks like rocket-science at a first glance, but could help you achieving fantastic performance in comparison to "usual locking".
First I have to do
#property (retain) aMember;
Then in implementation file I got to do
#synthesize aMember;
Then in dealloc, I got to do
self.aMember= nil; (or [aMember release])
That's 3 times writing what essentially is the same
Is there a way to speed this up?
I mean I can drag drop a control from a IB and xcode automatically generate those codes why I can't do that for more normal codes?
As someone coming from C# and managed languages for my day job I completely agree with you in questioning this 3 step process. In fact its almost crazy easy to create properties in C# in MS Visual Studio, but I digress.
Even though there are these 3 lines you have to write there is a huge amount of work going on under the covers for your.
Your declaration of the #property tells objective-c some important attributes (atomic, nonatomic, retain, copy, etc) in how to deal with your property when it is set by users of your class. When you think about this, these attributes (without you writing any code) are; helping you create thread safe code, handling references to objects so you don't have to worry about them disappearing on you, or copying values so you have your own copy of an object. The #property is also important since it is declared in your header file (typically). This give other developers an idea of the properties of your class and some small hints as to how objects they pass into those properties will be handled during its lifetime.
The #synthesize is also doing quite a bit of work by creating the getters and setters for that property, that also handle all sorts of memory management for you. You don't need to worry about releasing the old references and correctly referencing the new object. This alone to me is a great feature, especially when you are new to objective-c and it is easy to forget to deal with memory management at every turn. The #synthesize just does it for you and you don't have to write all the get and set code yourself.
The dealloc call is just life in a non-memory managed environment. While it adds additional steps, I appreciate the benefits that explicit memory management allows in a constrained environment such as the phone.
So all 3 steps are required, are different and when you think about it actually do quite a bit of work for you under the covers.
Unfortunately, that's how it is (for now). Apple had recently toyed with allowing Clang to implicitly synthesize your properties, which would have reduced your work to:
#interface Blah : NSObject
#property (retain) Blorg *blorg;
#end
#implementation Blah
- (void)dealloc {
[blorg release];
[super dealloc];
}
#end
When you didn't want an instance variable to be synthesized, you'd just explicitly put #dynamic blorg in your implementation. But this feature was removed due to some unforeseen complications, despite mostly positive reactions from developers.
So, I think it's safe to expect that Apple's still working on this. But for now, you do need to explicitly synthesize.
A few other notes:
If you are using garbage collection, you don't need to implement -dealloc: just make sure to do any last-minute cleanup in -finalize (such as notification unregistration).
You could also avoid the -dealloc bit by wrapping your instance variable in a C++ class which performs memory management during construction and destruction: #property prop_wrapper<Blorg> blorg; would work. Then, when your object is destroyed, ~prop_wrapper() would be called on your object. I've done this, and it works, but I recommend against it, since it doesn't play nice with KVO and KVC.
You could iterate through the properties of an object, and release those that are annotated with copy or retain. Then, in -dealloc, you'd have something like [self releaseProperties]. I've also done this, but I also recommend against it, since it can cause subtle problems which may result in inexplicable crashes if you're not careful.
To actually add a member variable in objective-c you don't need to do any of that.
What you're doing in those 3 steps is:
Declare properties for a member variable. (In your case you are indicating that you want the property setter to 'retain' the object that it sets your member variable to)
Declare the property getters and setters in a default way for your property.
Release the object that your property is retaining.
IF you only wanted to declare a member variable, all you had to do was declare it inside your class:
#interface SomeClassObject : NSObject {
int someMemberVariable;
}
#end
That's 3 times writing what essentially is the same
No it isn't.
#property (retain) aMember;
The above line declares a property so that the compiler knows it is OK to send the messages -aMember and -setAMember: to objects of your class. It also tells the compiler (and developers) that the property is a retain property (i.e. the object you set the property to will be retained), that it is read/write and that it is atomic.
#synthesize aMember;
The above line tells the compiler that it should automatically generate the setter and getter methods for the declared property. You can leave that out but then you have to write your own setter and getter.
[aMember release]; // in dealloc
Is there to tell the runtime that when the object is being deallocated, it no longer needs to hold a reference to that instance variable. This is necessary because, when you use reference counting rather than garbage collection, the runtime does not automatically clean up unwanted objects.
Each of those lines does a different thing. So you are not doing the same thing three times.