c# - C++ 或 C# 来编程移动条码设备？

Question

我将使用移动条码扫描器开发一些应用程序，需要在 C++ 和 C# 之间进行选择 在扫描仪上编码。

我正在考虑 Intermec's CK31或类似的 wifi、扫描选项、可编程性和用户界面选项的组合。它根据他们的规范表运行 Windows CE .NET 4.2。

Intermec's Developer Library带有 .Net 和 C++ SDK。我以前的 Win CE 2003 经验是 C++(MFC GUI、套接字和串行通信)。我对 C# 和 WPF 很熟悉，如果需要，我可以学习其他 GUI 框架。这让我可以自由选择一种语言 - 有什么建议吗？

我是 不是 寻找提倡 C++ 而非 C# 作为一般语言的答案——我在这两种语言中的生产力是相似的，而且我有足够的经验能够创建复杂、健壮的 C++ 解决方案。

我希望能加入我们平台评估的 war 故事或因素，关于编程在这些设备上 .例如:C# 应用程序与 C++ 应用程序的电池生命周期、内存消耗或语言选择的其他环境影响。如果要避免使用特定版本的 .Net CE，那将是一个很好的提示。

Answer 1

几年来，我一直在用 C、C++ 和 C# 为 Windows Mobile 和 Windows CE 设计和开发软件。此外，我一直在为 Honeywell(前身为 Hand Held Products，于 2007 年被 Honeywell 收购)这样做，在那里我几乎研究了设备的所有方面，从驱动程序和服务到业务线 GUI 和实用程序。

首先，我不会告诉你一种语言比另一种更好......我可能会花 50/50 的时间在每个平台上，每个平台在移动开发中肯定都有自己的位置。

但是，我会建议您远离任何运行与 WinCE 4.2 一样旧的操作系统的设备，尤其是如果您甚至正在考虑 .NET 开发。这样做的原因是 4.2 最多只将 .NET CF 1.0 嵌入到 ROM(OS ROM 镜像的一部分)中，这意味着您至少需要大约 5MB 的 CAB 文件才能安装 .NET CF 2.0 是的，您可以使用 CF 1.0 进行开发，但实际上，使用这样一个旧框架的痛苦是不值得的。现在大多数 WinCE 5.0 设备都在 ROM 中安装了 CF(Compact Framework)2.0，所以我至少会寻找它。

同样徒劳无功，您甚至可能需要考虑使用装有 Windows Mobile 6.0 或 6.1 的设备，因为它们易于编程并且始终预装 CF 2.0。如果您想知道为什么我没有提到 CF 3.0 或 CF 3.5，那只是因为与这些版本一起发布的第一个移动平台将是尚未发布的 Windows Mobile 6.5。尽管您可以随时根据需要安装该框架(~8MB CAB)。

诚然，与 Windows Mobile 同类产品相比，WinCE 绝对为您提供了更“Windows”的 GUI 外观和感觉，因此这完全取决于您的编程偏好以及您的最终用户想要和需要什么。

关于kgiannakakis's对 SDK 只是事物层的评论，这是不正确的。如果您有合适的 SDK，您应该可以像在 C++ 中那样访问任何设备或驱动程序，但要使用 C#。例如，Honeywell 为我们所有的设备提供了一个广泛的 SDK，使用 C++、VB 和 C#，而 SDK 的 C# 部分实际上有 更多 功能比 C++ 部分。您将永远不必使用我们的 C# 代码执行 P/Invoke。

如果你想看看我所说的 SDK，它可以免费下载 here并有一些很好的例子。
恕我直言，在许多情况下，我实际上认为提供的 SDK 比硬件更重要，因为在大多数情况下，设备的硬件几乎相同。它们都有 ARM CPU、WiFi、蓝牙、激光或基于图像的扫描仪等。
不过，我查看了您发布的 Intermec 链接，但看起来该设备实际上并没有内置扫描仪……您是否使用连接到设备的外部扫描仪？
如果需要，请查看霍尼韦尔产品 here .我们的设备可能配备业内最好的基于成像器的条码扫描器，内置于我们的所有设备中。我们有一个坚如磐石的 SDK(我应该知道，我写了很多)。 SDK 为 .NET 提供了对设备上所有硬件的极其访问。好的...我现在就停止我的推销。

至于一种语言而不是另一种语言……这完全取决于您究竟想做什么。

驱动程序和服务只能用 Native (Win32) C 或 C++ 编写。所以 .NET 就是为了这样的东西。
在保持轻量级方面，C 和 C++ 绝对可以成为您在移动设备上的 friend ，因为您不需要整个 .NET 框架来运行添加。请记住，任何进程(不包括 DLL ..这是另一讲)的最大内存为 32MB，因此如果您的应用程序要处理大量数据，C++ 可能是要走的路。

然而，我发现在移动系统上使用 C 和 C++ 的主要缺点之一是制作 GUI 比使用 .NET 困难得多实际上，我编写的大多数 C++ 应用程序都是完全 headless 的，并且没有 GUI所有... .NET CF 还没有 WPF(还没有)，并且被 WinForms 困住了，但它真的很容易上手。设计师几乎可以拖放。还要记住，就像我之前提到的，WinCE 具有与 Windows Mobile 完全不同的 GUI 范例。然而，有时 Windows Mobile 方式还是不错的，因为它迫使您保持 GUI 的简单和切中要害。

使用 .NET 时内存消耗可能更高，但并非总是如此。一方面，将要使用的 CF 版本存储在 ROM 中的设备意味着与等效的 C++ 应用程序相比，.NET 应用程序通常不会使用更多内存。在某些情况下，.NET 甚至会使用更少的内存。例如，.NET 应用程序与使用 MFC 的 C++ 应用程序通常可以使用较少的内存，因为 C++ 应用程序必须加载 MFC 框架(因为它尚未被操作系统加载......)。
此外，由于 C# 是托管的，因此您通常会减少内存使用量，因为垃圾收集器正在释放您可能忘记在 C++ 应用程序中执行的内存。

两者在更现代的设备上的执行速度通常没有区别。诚然，每种语言的一小部分总是会比另一种更快，但 .NET 在这一点上已经足够成熟，速度并不是真正的问题。我编写了具有高度交互性、动画 GUI 的极快应用程序，这些应用程序在具有 128MB RAM 和 420MHz ARM CPU 的设备上运行得很好。我什至写了一个应用程序，我不得不放慢速度，因为它通过 P/Invoke 调用本地 DLL，而 .NET 部分基本上变得“不耐烦”。

我从未见过一种语言与另一种语言的电池生命周期问题。但我也从来没有专门测试过。

我真的认为，最终，它仍然归结为您选择的设备附带的 SDK。如果它对 .NET 的支持很差，那么你会发现你自己做了很多额外的工作来让一切正常工作，在这种情况下我会选择 C++。但是如果它有很好的 .NET 支持(就像我工作的那个)，你会发现自己的工作少了很多，而且可能会更快地完成工作。

另外，请记住，您必须考虑的不仅仅是硬件供应商的 SDK。虽然您需要特定的 SDK，因为每个设备都不同(即我之前链接的 SDK 无法在该 Intermec 设备上运行)所有非硬件相关的操作系统内容都是全面的标准，这就是 Windows Mobile或者来自微软的 Windows CE SDK 进来了。他们的 C++ 支持非常好，但他们现在真的在插入所有的东西。依赖于使用 .NET 并不是说​​你不能在 C++ 中做到这一点，只是他们没有为你完成他们在 .NET SDK 中所做的很多工作。

好吧……那很长，但我正试图将我多年经验中更精细的部分转化为一件事。我希望这是有道理的。