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

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

我正在考虑Intermec的CK31或类似的WiFi,扫描选择,可编程性和用户界面选项的组合.它根据规格表运行Windows CE .NET 4.2.

Intermec的开发人员库附带.Net和C++ SDK.我以前的Win CE 2003经验是用C++(MFC GUI,套接字和串行通信).我对使用WPF的C#很满意,如果必须的话可以学习其他GUI框架.这让我可以自由选择语言 - 任何建议都是这样或那样的？

我不是在寻找C++而不是C#作为语言的答案 - 我的生产力都很相似,而且我有足够的经验来创建复杂,强大的C++解决方案.

我将欣赏的是战争故事或因素,我们的平台评估,以及这些设备上的编程.例如:C#apps与C++应用程序的电池寿命,内存消耗或语言选择的其他环境影响.如果有特定版本的.Net CE要避免,那将是一个很好的提示.

我已经用C,C++和C#设计和开发Windows Mobile和Windows CE软件已经有好几年了.此外,我一直在为霍尼韦尔(以前的手持产品,2007年由Honeywell购买)这样做,我从事过几乎所有设备的工作,从驱动程序和服务到业务线图GUI和实用程序.

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

但是,我会建议您远离任何运行与WinCE 4.2一样旧的操作系统的设备,特别是如果您甚至考虑使用.NET开发.这样做的原因是4.2最多只有嵌入在ROM中的.NET CF 1.0(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).

当然,WinCE肯定会通过其Windows Mobile表亲为其GUI提供更多"Windows"外观和感觉,因此这完全取决于您的编程偏好以及您的最终用户想要和需要的内容.

关于kgiannakakis对SDK 的评论只是一个事物层,这是不正确的.如果您有一个合适的SDK,您应该具有与C++相同但具有C#易用性的任何设备或驱动程序的所有相同访问权限.例如,霍尼韦尔为C++,VB和C#中的所有设备提供了广泛的SDK,而SDK的C#部分实际上具有比C++部分更多的功能.您永远不必使用我们的C#代码进行P/Invoke.

如果你想看看我正在谈论的SDK,它可以在这里免费下载并有一些很好的例子.恕我直言,在许多情况下,我会认为提供的SDK比硬件更重要,因为大多数情况下,设备的硬件几乎是相同的.他们都有ARM CPU,WiFi,蓝牙,激光或基于图像的扫描仪等.虽然,我看了你发布的Intermec链接,看起来这个单位实际上没有内置的扫描仪......你使用的是外部扫描仪挂在设备上？如果你想看看霍尼韦尔发售这里.我们的设备可能是业内最好的基于成像器的条形码扫描仪,内置于我们所有的单元中.我们有一个坚如磐石的SDK(我应该知道,我写了很多).SDK为.NET提供了对设备上所有硬件的极大访问权限.好的......我现在就停止销售.

至于另一种语言......它实际上取决于你想要做什么.

驱动程序和服务不能用Native(Win32)C或C++编写.所以.NET就是出类拔萃的.在保持轻量级方面,C和C++绝对可以成为您在移动设备上的朋友,因为您不需要整个.NET框架来运行添加.请记住,任何进程最多都有32MB的内存(不包括DLL ......这是另一个讲座)所以如果你的应用程序要处理大量数据,那么C++可能就是你的选择.

其中一个主要的缺点我发现C和C++在移动系统上的,但是,是使一个GUI的方式难度比它与.NET其实,大多数的C++应用程序我写的是完全无头,没有GUI在所有... .NET CF 没有 WPF(尚未),并且坚持使用WinForms,但它很容易上手.在设计师中几乎拖放.并且还记得,就像我之前提到的那样,WinCE具有与Windows Mobile完全不同的GUI范例.但是,有时Windows Mobile方式很不错,因为它会强制您保持GUI的简单性和重点.

使用.NET时,内存消耗可能会更高,但并非总是如此.首先,如果设备具有存储在ROM中的CF版本,则意味着您通常不会在.NET应用程序上使用相同的C++应用程序.在某些情况下,.NET甚至会使用更少的内存.例如,.NET应用程序与使用MFC的C++应用程序通常可以使用更少的内存,因为C++应用程序必须加载MFC框架(因为它尚未由OS加载...).此外,由于C#是受管理的,因此通常会减少内存使用量,因为垃圾收集器释放了您可能忘记在C++应用程序中执行的内存.

更现代的设备上的执行速度通常在两者之间没有差异.当然,每种语言都会有一小部分,其中一种语言比另一种语言更快,但.NET在这一点上已经足够成熟,速度并不是真正的问题.我已经使用高度交互式的动画GUI编写了极快的应用程序,这些GUI在具有128MB RAM和420MHz ARM CPU的设备上运行得很好.我甚至编写了一个我不得不放慢速度的应用程序,因为它通过P/Invoke调用了本机DLL,而.NET部分实际上变得"不耐烦".

我从未见过一种语言与另一种语言的电池寿命问题.但我从来没有专门测试它.

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

此外,请记住,您不仅要考虑硬件供应商的SDK.虽然你需要那个特定的SDK,因为每个设备都不同(即我之前链接的SDK 不能在那个Intermec设备上运行)所有非硬件相关的操作系统内容都是全面的标准,这是Windows Mobile的地方或者来自Microsoft的Windows CE SDK.他们的C++支持非常好,但是他们现在真的推动.NET的所有工作,所以当对操作系统进行更新时,对C++ SDK的更新更少,现在更多的功能依赖于使用.NET不是说你不能做它在C++中,这只是他们没有这样做很多关于你的工作,他们的根本在.NET SDK做.

好的......那很长,但我试图将我多年经验的细节转化为一件事.我希望这是有道理的.