为什么Objective-C对象必须动态分配？ [英] Why do Objective-C objects have to be dynamically allocated?
问题描述
为什么必须动态分配Objective-c对象？为什么我必须让它指向一个对象，不像在C + +我可以创建他们在堆栈？
谢谢。
主要原因：不知道要保留多少堆栈大小。
动态消息在这种情况下无关紧要，因为设置正确的 vtable'在初始化时是微不足道的。
在c ++中，堆栈对象的大小总是已知的（如果它错了，你知道预期什么）。一个objc alloc / init序列可以返回几种类型中的任何一种 - 每种类型都有不同的大小（它本质上是一个工厂），或者根本没有。
。
更新1
我很好奇这个，所以我做一个小测试程序作为一个概念的证明。
我能够实现一个简单的堆栈objc类层次结构，它也实现了一个很好的 NSObject 的接口 - 当然，省略引用计数和动态分配接口，因为它不涉及概念证明。无论如何，我的简单类层次结构不是与NSObject类或协议完全兼容，因此它不是应该使用NSObject类型的地方，显而易见的原因。因此，如果你真的想要基于堆栈的objc对象，则是可能的（而不是特别困难）。
必须做任何不同于c ++以保留堆栈空间。要保留的堆栈大小在某些区域仍然是一个限制（考虑工厂方法，类集群等）。
还有一些运行时功能，不能工作默认。这里最好的例子是在运行时添加ivars的能力。你可以事实上适应这个功能，如果你需要它。我没有打扰这个练习。
自然，基本接口可能会有几个偏差 - 我为乐趣一个偏差是添加了交换实现的能力
更新2
p>事实证明，GCC接受我写的概念证明。不幸的是，由于在保留正确的大小（考虑到语言的动态特性...）可能遇到的问题/危险，这已被禁止铛。示例：clang forbids sizeof（NSObject）。哦。
Why do Objective-c objects have to be dynamically allocated? Why do I have to make it a pointer to an object, unlike in C++ I can create them on stack? Thanks.
the primary reason: not knowing how much stack size to reserve.
existing conventions and uses also make lifting the restriction quite difficult.
dynamic messaging does not matter in this case, as setting the right 'vtable' at initialization is trivial.
in c++, the size of a stack object is always known (and if it's wrong, you know what to expect). an objc alloc/init sequence can return any one of several types -- each with different sizes (it's essentially a factory), or nothing at all.
the size can also vary at runtime (e.g. you can add fields to a class via the runtime).
Update 1
i was curious about this, so i made a little test program as a proof of concept.
i was able to implement a simple stack based objc class hierarchy, which also implemented a good chunk of NSObject's interface -- of course, omitting the reference counting and dynamic allocation interfaces as it did not relate to the proof of concept. at any rate, my simple class hierarchy was not fully compatible with the NSObject class or protocol, so it isn't something that should be used where NSObject types are expected, for obvious reasons. therefore, it is possible (and not particularly difficult) to accomplish this, if you really wanted stack based objc objects.
you don't have to do anything different from c++ to reserve the stack space. the stack size to reserve is still a restriction in some areas (consider factory methods, class clusters, etc.).
there are also a few runtime functionalities which will not work by default. the best example here is the ability to add ivars at runtime. you could in fact accomodate this functionality, if you needed it. i didn't bother with that exercise.
naturally, the base interface could take several deviations - one deviation that i made for fun was adding the ability to exchange the implementations (type) of a living object.
have fun
Update 2
as it turns out, GCC accepts the proof of concept i wrote. unfortunately, this has been banned in clang due to problems/dangers which can be encountered in reserving the correct size (considering the dynamic features of the language...). example: clang forbids sizeof(NSObject). oh well.
这篇关于为什么Objective-C对象必须动态分配？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
