问题描述
我想创建一个 NSMutableArray 来表示容纳网格元素的游戏板(假设我有一个 chess 类).在这种情况下，我已经知道了电路板的大小，因此我想通过 initWithCapacity:[size] 创建一个数组，然后将其初始化为 nil .在游戏过程中，我可能会根据游戏在此数组中插入或删除 chess 对象.有时候我需要检查某些单元格是否为 nil .
I want to create a NSMutableArray to represent a game board that holds grid element (assume I have a chess class). In this case, I already know the size of the board so I want to create an array by initWithCapacity:[size] and then initialize them as nil. During the game, I may insert or remove chess object into/from this array based on game. I need to check if some cell is nil sometimes.
很显然， initWithCapacity 仅分配内存，但是给出了一个空数组，其元素不可评估.我认为一一插入 [NSNull null] 效率不高(我可以使用0来表示 nil ，但仍然不是我想要的).
Clearly initWithCapacity only allocate memory, but gives an empty array whose element is not assessable. I think insert [NSNull null] one by one is inefficient (I can turn to use 0 to represent nil but still not what I want).
在目标C中是否有任何类型/结构(例如C/C ++数组)用于我的目的?还是在这里使用C/C ++数组是明智的选择?(例如 Chess myArray [size] )
Is there any type/structure in Objective C like a C/C++ array for my purpose? Or is it wise to use C/C++ array here? (e.g. Chess myArray[size])
推荐答案
设计是， NSMutableArray 和其他集合不允许 nil 和 [NSNull null] 用作无"概念的占位符.
It is by design that NSMutableArrays and other collections do not permit nil and [NSNull null] is used as a placeholder for the concept of "nothing" instead.
[NSNull null] 是单例，因此不会不必要地分配大量内存，并且效率不高.
[NSNull null] is a singleton, so won't allocate lots of memory unnecessarily and is not inefficient.
此答案具有更多信息.
100个元素不是问题.您的设备将能够非常快速迭代100个元素.如果愿意，可以定时.
100 elements isn't a problem. Your device will be able to iterate 100 elements very quickly. Time it if you like.
这是我想到的第一种方式.
It's the first way I would think of doing it.
过早的优化是万恶之源"
您似乎太早专注于优化.此时，您应该优先选择可读性而不是效率.
You seem to be concentrating on optimisation too early. You should favour readability over efficiency at this point.
当您的应用程序似乎变慢或即将发布时，请对该应用程序进行概要分析，并找出可能存在的问题.否则，您可能会发现自己花了一天的时间优化" for循环，以发现每次更新节省了0.000001秒.
When your app seems to slow down, or near the end of a release, profile the application and find out what, if any problems exist. Otherwise you may find yourself spending a day "optimising" a for loop to find that you've saved 0.000001s per update.
此外，可读代码更容易:
Moreover, readable code is easier to:
- 调试
- 更新
- 维护
- 分享
经过微优化的代码需要更长的时间来生成，容易出现 bug ，难以进行 debug 和维护并且通常无法共享，因为其他开发人员可能不知道如何解释您的优化.
Micro-optimised code takes longer to produce, is prone to bugs, difficult to debug and maintain and often impossible to share as another developer may not know how to interpret your optimisations.
并不是说不乐观"，而是专注于优化最大的问题.
That's not to say "don't optimise", rather concentrate on optimising the biggest problems.
这篇关于Objective C NSMutableArray使用nil的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！