-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why __strong __typeof(weakSelf)strongSelf = weakSelf ? #20
Comments
Unfortunately they are not. Just referencing 'self' within a block will cause the block to retain it and in this case, it will cause a retain cycle (because you know... self would be captured within the block). |
I'm just curious: how one can reproduce this issue after enabling
Clang produced no warnings. |
Ha! I've found a sample code how to reproduce this issue with implicit retain. However, using
|
Still can't figure out why compiler ignored retain cycle in |
@nskboy you have a retain cycle only if your class is holding a strong reference to the NSURLConnection. Given that is a completion block, this means that you need to keep it alway only for the duration of the request, if the class (NSURLConnection in this case) internally nil-out the strong reference to completion block you don't have a retain cycle. |
__typeof(self) can't create a retain cycle because __typeof is complie-time-only operator. |
On other hand |
Thanks @notorca, apologise for the big mistake. You're absolutely right: And sure, |
Thanks, so they are the same :) Some people ask me these questions
I collect the answers in UNDERSTANDING WEAK SELF AND STRONG SELF, hope you can take a look at it |
@lukabernardi thanks for clarification! |
@onmyway133 the reason about the use of weakSelf and strongSelf are also explained in the book https://github.com/objc-zen/objc-zen-book#retain-cycles-on-self |
There is another problem, self can be implicitly captured in the block if ivar is accessed.
To avoid this I created macro:
And for cases with ivar:
In debug version this macro also checks for "accidental" capturing of the self throw ivars and asserts in runtime when block is created. You can find it here: https://gist.github.com/notorca/9192459#file-weakself-h |
There are more subtle ways in which self is referenced inside block, like NSAssert http://sealedabstract.com/code/nsnotificationcenter-with-blocks-considered-harmful/ |
@onmyway133 yes, my macro also handles situation with NSAssert. |
@onmyway133 [NSNotificationCenter defaultCenter] is still on the main thread, there is no need to do this, I think. |
@onmyway133 But doing this, you will never cause a retain cycle, unless you are sure about that. |
I've error something like this. File Name is xxxx.m Anyone help me. |
Just I found solution . replace __weak typeof(self) weakSelf = self; __weak __typeof(self) weakSelf = self; and |
I know this project is about coding convention, but you tried to explain block and its usage, so I ask
In the "Block" section,
Why typeof(weakSelf) instead of typeof(self)? Aren't they the same thing ?
The text was updated successfully, but these errors were encountered: