C++或C#编程移动条码设备？我将使用移动条形码扫描仪开发一些应用程序，需要在C++和C#之间进行选择以在扫描仪上进行编码。我正在考虑Intermec的CK31或WiFi、扫描选择、可编程性和用户界面选项的类似组合。根据规格表，它运行WindowsCE.NET4.2。Intermec的开发人员库附带.Net和C++SDK。我以前的WinCE2003经验是使用C++（MFCGUI、套接字和串行通信）。我对使用WPF的C#很满意，如果需要，可以学习其他GUI框架。这让我可以自由选择语言-有任何建议吗？我不是在寻找C++而不是C#作为一种语言的答案——我同样富有成效，而且我有足够的经验来创建复杂、健壮的C++解决方案。我将欣赏的是战争故事或因素、我们的平台评估以及这些设备上的编程。例如：C#应用程序与C++应用程序的电池寿命、内存消耗或语言选择的其他环境影响。如果您想避免特定版本的.NetCE，那将是一个很好的提示。多年来，我一直在使用C、C++和C#设计和开发WindowsMobile和WindowsCE软件。此外，我一直在为Honeywell（前掌上电脑，2007年被Honeywell收购）做这件事，我从事过从驱动程序和服务到业务线图GUI和实用程序的几乎所有工作。首先，我不会告诉你一种语言比另一种语言好......我每次大概花费50/50的时间，每个平台在移动开发中肯定都有它的位置。但是，我建议远离任何运行WinCE4.2等旧操作系统的设备，尤其是在您甚至考虑进行.NET开发的情况下。这样做的原因是4.2最多只在ROM中嵌入了.NETCF1.0（OSROM映像的一部分），这意味着您需要一个~5MB的CAB文件来安装至少.NETCF2.0是的，您可以使用CF1.0，但真的，不值得使用这么老的框架。现在大多数WinCE5.0设备都在ROM中安装了CF（CompactFramework）2.0，所以我至少会寻找它。同样徒劳的是，您甚至可能想考虑使用WindowsMobile6.0或6.1设备，因为它们易于编程并且始终预装CF2.0。如果您想知道为什么我没有提到CF3.0或CF3.5，那只是因为第一个随这些版本一起发布的移动平台将是WindowsMobile6.5，它还没有发布。尽管您始终可以安装该框架（~8MBCAB）。当然，与WindowsMobile表亲相比，WinCE无疑为其GUI提供了更“Windows”的外观和感觉，因此这完全取决于您的编程偏好以及您的最终用户的需求。关于kgiannakakis认为SDK只是一层东西的评论，这是不正确的。如果您有合适的SDK，您应该可以像在C++中一样访问任何设备或驱动程序，但使用C#很容易。例如，霍尼韦尔以C++、VB和C#为所有设备提供了广泛的SDK，而SDK的C#部分实际上比C++部分具有更多的功能。您永远不必使用我们的C#代码进行P/Invoke。如果您想查看我正在谈论的SDK，可以在此处免费下载并提供一些很好的示例。恕我直言，我实际上认为在很多情况下提供的SDK比硬件更重要，因为大多数时候，设备的硬件几乎是一样的。他们都有ARMCPU、WiFi、蓝牙、激光或基于图像的扫描仪等。虽然，我查看了您发布的Intermec链接，但看起来该装置实际上没有内置扫描仪……您使用的是外部扫描仪吗扫描仪连接到设备？如果需要，请查看霍尼韦尔产品。我们的设备可能是业内最好的基于图像的条码扫描仪，内置于我们所有的设备中。我们有一个坚如磐石的SDK（我应该知道，我写了很多）。SDK使.NET能够极大地访问设备上的所有硬件。好吧……我现在要停止销售了。至于另一种语言……这真的取决于你想做什么。驱动程序和服务不能用本机(Win32)C或C++编写。所以.NET是课程的标准。在保持轻量级方面，C和C++绝对可以成为您在移动设备上的朋友，因为您不需要整个.NET框架来运行添加。请记住，任何进程最多有32MB的内存（不包括DLL……那是另一回事），因此如果您的应用程序要处理大量数据，那么C++可能是最佳选择。然而，我发现在移动系统上使用C和C++的主要缺点之一是获得GUI比使用.NET更难。事实上，我编写的大多数C++应用程序都是无头的，根本没有GUI....NETCF没有WPF（还）并且坚持使用WinForms，但它很容易上手。在设计器中虚拟拖放。请记住，正如我之前提到的，WinCE具有与WindowsMobile完全不同的GUI范例。然而，有时WindowsMobile的方式是好的，因为它迫使您保持GUI简单和集中。使用.NET时内存消耗可能更高，但并非总是如此。首先，将您将要使用的CF版本的设备存储在ROM中意味着您通常不会在.NET应用程序上使用比等效的C++应用程序更多的内存。在某些情况下，.NET甚至会使用更少的内存。例如，.NET应用程序通常可以比使用MFC的C++应用程序使用更少的内存，因为C++应用程序必须加载MFC框架（因为操作系统尚未加载它......）。此外，由于C#是托管的，内存使用量通常会减少，因为垃圾收集器会释放您可能忘记在C++应用程序中执行的内存。更现代设备上的执行速度通常在两者之间没有区别。当然，每种语言都有一小部分比另一种更快，但.NET在这一点上已经足够成熟，速度并不是真正的问题。我使用高度交互的动画GUI编写了速度极快的应用程序，这些应用程序在具有128MBRAM和420MHzARMCPU的设备上运行得很好。我什至编写了一个我不得不放慢速度的应用程序，因为它通过P/Invoke调用本机DLL，而.NET部分实际上变得“不耐烦”。我从未见过一种语言与另一种语言的电池寿命问题。但我从来没有专门测试过它。我真的认为，最终，它仍然归结为您选择的设备随附的SDK。如果它对.NET的支持很差，那么您会发现自己需要做很多额外的工作才能使一切正常工作，在这种情况下我会选择C++。但是，如果它有良好的.NET支持（就像我所从事的那样），您会发现自己所做的工作要少得多，而且可能会更快地完成工作。另外，请记住，您不必只考虑硬件供应商的SDK。虽然您需要特定的SDK，因为每个设备都不同（即我之前链接到的SDK不适用于该Intermec设备），但所有与硬件无关的操作系统都是相当标准的，这就是WindowsMobile来自MicrosoftWindows的地方开发工具包。他们的C++支持还是不错的，但是他们现在真的是把所有的工作都推到.NET里面了，所以在OS更新的时候，C++SDK的更新比较少，现在更多的功能依赖于使用.NET不是你不能用C++做，只是没有为他们做很多工作，他们在.NETSDK中做。好吧……这很长，但我正在尝试将我多年经验中的细节转化为一件事。我希望这是有道理的。您问题的答案取决于您的申请类型。如果您的应用程序主要是与硬件通信，并且只需要薄层的业务逻辑和用户界面，那么C++将是更好的选择。要与扫描仪交互，您需要与驱动程序通信。使用C++可以更好更快地实现这一点。.NETSDK实际上是对使用大量P/Invoke的C++代码的包装，这使得代码执行速度更快。另一方面，如果您的应用程序需要重要的业务层和/或用户界面，那么.NET（尤其是C#）是更好的选择。在这种情况下，生产力的提高远远超过C++的性能提高。另一个重要因素是应用程序将部署到的设备类型。您是否仅针对WindowsMobile设备？那么.NET是一个安全的选择。对于WindowsCE设备，您需要调查是否预装了紧凑框架。此外，某些WindowsCE设备可能不支持所有.NET名称空间。最后，我建议阅读移动架构袖珍指南，这是一份关于移动应用程序架构决策的最新文档。首先，出于同样的原因，我强烈赞同Adam建议此时运行基于CE.NET4.2的任何东西。在这一点上，它是一个古老的操作系统版本，除非您免费获得终端，否则不值得，如果您选择进行C#开发，下载CAB以运行.NET2将是一个真正的痛苦。我们为Motorola(Symbol)和Intermec设备开发了许多应用程序。他们当前的API集工作可靠，所以我更担心设备适用性而不是特定API。他们还提供合理的示例程序，使剪切和粘贴解决方案变得容易。我注意到摩托罗拉和Intermec之间的另一个重大差异。在我使用的Intermec设备上（在C#中），每个符号的解码器大约需要一秒钟的时间来加载。如果您使用有限数量的符号并在应用程序启动时设置扫描仪，这通常不是什么大问题，但如果您更改应用程序中的解码器（符号），则可能会导致严重延迟。我已经开发了大约15年。大约5年的C++和3年的C#（目前我选择的语言）。在C++中，我总是使用stdlib，有时使用boost。自从我从C++切换到C#后，我的开发时间减少了三分之一。这是因为几件事（没有科学依据，只是我的看法）：.Net是一个更完整的框架，比stdlib和boost的组合更易于使用。C#有更好的结构，更容易阅读其他代码和代码。在使用C++进行单元测试时，.Net中的单元测试非常少，尤其是使用Resharper和xUnit（xUnit语法清晰，resharper允许您直接在devstudio中测试特定的测试方法）。我主要是代码服务器，GUI编程应该更快。以上就是C#学习教程：C++还是C#编程移动条码器？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
