你怎么知道pushViewController保留了推送的对象？
这里的答案都说pushViewController保留了给定的viewController，但他们没有引用说明这一点的文件。
问题是他们如何知道 PushViewController 将保留给定的视图控制器？我们是否可以假设采用 NSObject* 派生对象指针的所有其他类都遵守此约定？
编辑：
我需要比当前给出的答案更有力的论证/证明。例如有关 UIView::addSubview 的文档 明确指出“此视图由接收者保留”。或者，如果您打算表明接收到的控制器是通过暗示保留的，因为 UINavigationController 与集合类具有相同的语义，那么可以通过表明它在内部使用集合类之一或引用一些声明的文档来表明它确实如此。这。 PushViewController 的文档说给定的视图控制器放置在“导航堆栈”上，但没有说明该堆栈是什么类。事实上，看UINavigationController头文件中的定义，看起来它并不是使用堆栈，而是使用NSMutableArray。如果您已经获得了数学学位并撰写了证明，那么您就会理解我正在寻找的那种智力严谨性。
The answers here all say that pushViewController retains the given viewController but they don't refer to a document that states this.
Question is how do they know that pushViewController will retain the given view controller? Can we assume that this convention is adhered to by all other classes that take your NSObject* derived object pointer?
Edit:
I need a stronger argument/proof than what the currently presented answers propose. For example the documentation about UIView::addSubview clearly states 'This view is retained by the receiver'. Alternatively, if you intend to show that the received controller is retained by implication because the UINavigationController has the same semantics as a collection class, then show that it does, by showing that it uses one of the collection classes internally or referencing some documentation that states this. The documentation for pushViewController says that the given view controller is placed on the 'navigation stack' but nowhere does it say what class this stack is. In fact, looking at the definition in the header file of the UINavigationController, it looks like it's not using a stack, but using NSMutableArray. If you've done a math's degree and written proofs then you'll understand the sort of intellectual rigor I'm looking for.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
因为收藏品永远拥有他们的物品，而父母永远拥有他们的孩子。
从某种意义上说，导航控制器的运行就像一种集合 - 堆栈。
如果控制器在导航控制器上消失并消失 - 那将是一个大问题。
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW1
Because collections always own their items, and parents always own their children.
In a sense, the navigation controller is operating like a type of collection - a stack.
If the controller up and disappeared on the navigation controller - that would be a big problem.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW1
你应该尝试这个，
你将被导航到堆栈中可用的任何其他先前的 ViewController。
you should try this
you'll be navigated to any other previous ViewController that are available in the stack.
苹果的文档从来都不是最严格的。使用
[NSString stringWithString:nil]会得到什么？[NSArray arrayWithArray:nil]？[NSURL URLWithString:nil]？（答案：一个异常、一个空数组，以及一个异常或 nil，具体取决于操作系统版本。）
归根结底，文档所说的内容并不那么重要。 Objective-C 主要是关于约定的，如果你理解约定，你通常会做对的。当存在文档未提及的边缘情况并且您没有测试，或者文档错误（iPhone 3G 上的 AVCapture 不支持 420v）或 Apple 更改了边缘情况发生的情况（上面有 NSURL，它意味着较旧的操作系统版本崩溃了，而较新的操作系统版本则正常），或者有人引入了错误（例如，640x480 420v 的 AVCapture 在 4.1/3GS 上挂起，但仅当您设置它 - 420v 是默认值，如果你不碰它，它就可以正常工作！）。
当出现问题时，指责文档也救不了你。即使这不是你的错，这仍然是你的问题：你的应用程序崩溃了，你应该为你的用户修复它（除非苹果阻止你这样做，这种情况也会发生）。
测试胜过文档。
Apple's documentation has never been the most rigorous. What do you get with
[NSString stringWithString:nil]?[NSArray arrayWithArray:nil]?[NSURL URLWithString:nil]?(Answers: An exception, an empty array, and either an exception or nil depending on OS version.)
At the end of the day, it doesn't matter that much what documentation says. Objective-C is largely about convention, and if you understand the conventions, you'll generally get it right. It goes wrong when there are edge cases the documentation didn't mention and you didn't test, or the documentation is wrong (AVCapture on iPhone 3G does not support 420v) or Apple changes what happens for edge cases (with NSURL above, it means that older OS versions crashed where newer ones were fine), or someone introduces a bug (e.g. AVCapture at 640x480 420v hangs on 4.1/3GS, but only if you set it - 420v is the default, and if you don't touch it it works fine!).
And when it goes wrong, pointing fingers at the documentation won't save you. Even if it's not your fault, it's still your problem: Your app crashes, and you owe it to your users to fix it (unless Apple prevents you from doing so, which happens too).
Testing beats documentation.
来自 视图控制器编程指南：
From the View Controller Programming Guide: