Question

当我们从“单一系统”应用程序转移到可以将任务分配到分布式处理节点的应用程序时，我们目前正在更改大量代码。现有代码混合使用非托管和现在托管的C ++代码，但也使用C＃代码在节点和控制器之间提供WCF接口。

作为此举的结果，我看到的可预见的未来可能会保留的公共代码模式是将整数ID值从MFC CArray基本转换为托管列表以启用WCF上的序列化。目前的模式是：

List<int>^ fixtures = gcnew List<int>(aFixtureIds.GetCount());

for(int i = 0; i < aFixtureIds.GetCount(); i++) //aFixtureIds is of MFC type CArray<int,int>
    {
        fixtures->Add(aFixtureIds[i]);
    }

我们也反过来使用类似的东西，如果返回一个List，我们可以通过在循环中迭代它并调用Add来将它转换为调用函数的CIntArray。

我很欣赏以上内容看起来并不是很密集但是它确实被调用了很多 - 是否有更好的模式来执行这个基本的List＆lt; - ＆gt; CArray转换会耗费更少的处理时间？这是编译器可以有效优化的那种代码（我怀疑不是，但我愿意纠正）？列表大小各不相同，但通常是1到数万个项目，可能更多。

Answer 1

一些建议虽然很多都取决于您的申请细节：

措施：我认为它变得陈旧，每个关于性能的SO问题让人们只是说“先测量”，但这通常是（总是？）好的建议，特别是在这种情况下。我担心你在估计这种转换在现代台式计算机上花费了多少时间。例如，在我4岁的桌面上，快速测试显示我可以在250毫秒内向CArray添加1亿个整数。我希望List中的C＃性能大致相同。这意味着您的10,000个元素列表需要大约25微秒才能运行。现在，很明显，如果你每秒做1000次，或者数十亿次元素就会成为一个问题，尽管这些情况下的解决方案不是更快的算法，而是更好的算法。
需要时更新：仅在您确实需要信息时更新阵列。如果您因为“可能”需要而频繁更新，则可能会浪费从未使用过的转化。
同步更新：而不是一次更新整个数组，而不是同时更新列表的两个副本中的元素。
只使用一个列表虽然听起来你不能这样做，但至少考虑使用一个列表而不是两个相同信息的副本。隐藏函数/方法/类中的元素访问权限，这样您就不需要知道数据是否存储在CArray＆lt;＆gt;中了。或列表＆lt;＆gt;。
更好的设计/算法：如果您测量并且您确实发现在此转换中花费了大量时间，那么您可能会通过将代码设计改进为更好的方式获得更好的回报减少或消除所需的转换。另一方面，仅仅复制CArray＆lt;＆gt;可能不会有很多改进。到列表＆lt;＆gt;。

在托管C ++中将MFC CArray <int>快速转换为List <int> </int> </int>

1 个答案: