语言选择:Windows Store应用程序的C ++或C#?

时间:2012-12-14 20:25:30

标签: c# c++ windows-runtime windows-store-apps c++-cx

我正在寻找关于哪种语言最好的一般意见。最好的考虑很多。

我在c,c ++和objective-c方面有很强的背景知识。我觉得这些很舒服3.我用的很少c#。我已经在固件和中间件方面工作了十多年,最近已经进入移动应用程序。主要是iOS,但现在扩展到Windows RT。

我即将为Windows应用商店编写我公司应用程序的版本(或者根据您想要调用的内容来编写Metro)。几个月前我使用C ++ / CX做了概念验证。学习它的障碍很少(ref类的语法,以及命名空间的大量使用),但这是过去的事情,我觉得它很舒服。

我发现的一些缺点是.net的大多数示例(包括MSDN和私有)都在c#中,c ++中较少。使用c ++来回答有关.net框架的问题似乎有点困难。大多数时候人们会发布一个c#的答案,我需要将它移植到c ++ equiv。有时这很容易,有时候更难。

我的问题是:是否值得我花时间和公司的时间重新开始使用c#而不是继续使用c ++?我需要拿起c#,但我不认为这是一个巨大的负担(实际上期待它)。一些担忧是: *获得更多工程师来处理此代码。我们公司将很快成长。找到一个了解c#vs MS专用c ++ / cx的工程师会更容易吗? *通过示例,文章和论坛轻松获得帮助。如果c#更常见,那就很有用。 *第三方库之间的兼容性(似乎可以使用任何主要语言的WinRT组件) * C#优于C ++的优势?他们都提供了我需要的这个应用程序,至少我能看到。 C#有哪些陷阱? * c#是否以与C ++ / CX相同的方式使用continution / lambdas进行asych编程?

我还没有考虑过任何其他优点/缺点吗?

你怎么看?另外,你有什么经验?你为什么要回答你的答案?

1 个答案:

答案 0 :(得分:1)

C#将拥有更好的在线支持(代码示例,问题答案)以及更强大的工程师基础。我的意思是,在这种特定的情况下,对于这种强大的Microsoft API依赖软件开发。 Windows Store在Microsoft的整体战略中非常重要,C#在语言策略方面比C ++更重要。因此,C#是合适的,IMO。


*编辑(Filip Skakun)我知道重新打开这个问题可能很难,所以我不能单独回答它,但我输入了所有可能有用的文本,所以我想我会添加它下面:

由您决定当然,根据您的信仰,这可能是一个非常主观的选择,例如,如果您认为C#的更高的潜在生产力和更好的工具和文档支持超过了更快的优势,更接近金属和(略微主观地)你已经知道的更便携的C ++。 C ++仍然是基于tiobe索引的语言的两倍,因此让C ++开发人员可能比C#开发人员更容易。 C ++ / CX是您只需要用于跨组装通信和与WinRT库交谈的东西,但您编写的任何其他内容都应该基于所有专家建议在标准C ++中完成。另请注意,C ++ / CX不是托管语言,您不能将它与.NET一起使用。它的语法高度相似,但是C ++ / CLI是一种托管语言。关于WinRT的好处是,如果您需要或需要,您可以使用这两种语言。我使用C#来处理所有XAML UI,网络,业务逻辑等。有很多样本可以使用C#和XAML,而C ++的范围有限,因为它只能用于带有WinRT的XAML平台。另一方面,对于任何较低级别,如使用DirectX或CPU密集型任务,我使用C ++,因为直接DirectX的文档比开源.NET包装器更多,当你想要挤出所有的时,它表现更好CPU的潜在功率或使用电池的最少能量。

C#是一种比C ++更简洁的语言,标点符号更少,新的async / await关键字使得异步调用(必须在Windows 8应用程序中使用)更加清晰。它也是一种托管语言,因此在大多数情况下你可能不需要关心何时释放内存,缓冲区溢出等。调试C#代码会产生比C ++更确定的结果(我花了2天时间调试一些C ++代码而且我仍然没有#39;知道我在找到这个bug的程度。由于调试非常简单,因此维护遗留代码也更容易。

C ++更快,因此它也使用更少的电池,您的应用程序将更快启动并可能使用更少的能源。如果您已经熟悉它,那么您可能比管理开发人群构建应用程序更具优势。因为它没有使用垃圾收集 - 内存管理更具确定性和轻量级,因此您的动画将更加流畅。

然后还有动机因素。如果你真的想学习C# - 你可能会比你已经知道的语言更开心,更有动力,更有效率地学习C#,并且乐于花更多时间学习它而不是你愿意花另一个C ++应用程序。

无论您使用哪种语言,底层WinRT库都是相同的,但.NET库仅在.NET代码中可用,标准C ++库仅在本机代码中可用。

最后 - 无论你做出什么决定 - 你总能混合两种语言。这可能会增加维护成本,因为未来维护代码的人可能需要知道这两种语言,并且混合语言平台非常年轻,工具支持稍微少一些(您无法进行混合托管+本机远程调试)例如)并且可能更多的马车。由于我之前说过的原因,在许多情况下这是一个非常好的选择。