ARC 所有权限定符的位置重要吗？
苹果倾向于给出这样的例子：
NSError __strong *error = nil;
或者，
-(BOOL)performOperationWithError:(NSError * __autoreleasing *)error;
如果我能这样做，我会发现它更具可读性和逻辑性：
__strong NSError *error = nil;
-(BOOL)performOperationWithError:(__autoreleasing NSError**)error;
快速测试显示编译器并没有抱怨我的编写方式。到底是我做错了，还是这样写就可以了？
Apple tends to give examples like this:
NSError __strong *error = nil;
or
-(BOOL)performOperationWithError:(NSError * __autoreleasing *)error;
I'd find it much more readable and logical if I could do it this way:
__strong NSError *error = nil;
-(BOOL)performOperationWithError:(__autoreleasing NSError**)error;
A quick test revealed that the compiler is not complaining about my way of writing it. Am I doing it wrong anyways, or is it just fine to write it like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，所有权限定符的位置根本不重要。由于所有权限定符仅对指向对象类型的指针有意义，因此您的意图绝不会含糊不清。无论您将其放在哪里，编译器都可以轻松地弄清楚您的意图，因此 ARC 正是这样做的。
如果您可以访问 iOS Apple 开发者论坛，那么您可以在 中看到我向 Apple 工程师提出了同样的问题https://devforums.apple.com/message/458606。
No, the position of the ownership qualifier doesn't matter at all. Since the ownership qualifiers only have meaning for pointer-to-object types, your intention is never ambiguous. The compiler can easily figure out what your intention is no matter where you place it, so ARC does exactly that.
If you have access to the iOS Apple Developer Forums, then you can see where I asked this same question of Apple's engineers at https://devforums.apple.com/message/458606.
如果编译器没有抱怨，并且您没有因此而得到任何新的泄漏，那么就很好了。您还可以比较一种方式与另一种方式的汇编输出，看看是否有任何差异（使用
diff工具，而不是 TextEdit，否则您将整晚都在处理它：P）如果 asm或二进制文件相同，那么编译器的处理方式完全相同。您还可以在前后使用 Instruments 进行测试，看看是否存在任何泄漏，以确保它仍然可以正确处理内存。
If the compiler doesn't complain, and you don't get any new leaks because of it, then it's good. You could also compare your assembly outputs from one way vs the other and see if there's any differences (use a
difftool, not TextEdit, or you'll be at it all night :P)If the asm or binaries are the same, then the compiler's treating it exactly the same. You could also test with Instruments before and after and see if there's any leakages, to make sure it's still handling memory correctly.