【问题标题】:Which platform should I use : native C++ or C#? [closed]我应该使用哪个平台:原生 C++ 或 C#? [关闭]
【发布时间】:2010-09-21 08:50:08
【问题描述】:

我想开发一个 Windows 应用程序。如果我使用原生 C++ 和 MFC 作为用户界面,那么应用程序将非常快速且小巧。但是使用 MFC 非常复杂。此外,如果我使用 C#,那么应用程序将比本机代码慢,并且它需要 .NET 框架才能运行。但是使用 WinForm 开发 GUI 非常容易。你更倾向哪个?

【问题讨论】:

  • 什么样的windows应用程序?你的目标操作系统是什么?答案很大程度上取决于您的目标。

标签: c# c++ user-interface mfc


【解决方案1】:

“快”和“慢”是主观的,尤其是对于当今的 PC。我并不是说故意让事情变慢,但编写托管应用程序的开销并不像您想象的那样几乎。 JIT 等可以很好地使代码执行得非常快。如果您确实需要,您还可以使用 NGEN 来提高启动速度。

实际上,如果您有时间学习它,您可能想要考虑 WPF 而不是 winform - 这是一种不同的技能组合,但可以让您很好地利用图形硬件等。

另外 - .NET 框架附带新的操作系统安装,并且在那些早于它的操作系统中仍然很常见。所以对我来说,使用 C#/.NET 开发将是一个相当明确的选择。开发一个强大且经过全面测试 C++ 应用程序(没有泄漏等)的时间(至少对我来说)比使用 C# 的时间要长得多。

【讨论】:

  • 是的,c#.net 在这里似乎是一个更实用的选择。
  • 我认为“主观慢”不再是由开销决定的,而是主要由 UI 的响应能力决定。
  • 制作一个没有泄漏的应用程序是一件容易的事.. 如果你构建.. 我多年来没有泄漏。也就是说..我也会选择 C#.. 只是一个更大的市场。
【解决方案2】:

注意不要过早优化;您提到了代码的速度,但对于大多数 Windows 用户界面操作,差异并不明显,因为绘图和磁盘访问的主要瓶颈对于这两种方法都没有不同。

我的建议是您使用 C# 和 WPF 或 WinForms 作为您的用户界面。如果您遇到一些减速,请使用分析器确定在哪里,然后考虑用本机代码替换一些业务逻辑,但前提是有好处。

【讨论】:

    【解决方案3】:

    有很多可能的 Windows 应用程序,每个应用程序都有自己的要求。

    如果您的应用程序需要快速(而我的工作就是这样做),那么原生 C++ 是一个不错的选择。

    如果您的应用程序需要很小(也许是为了在慢速线路上进行真正快速的传输),那么请使用任何使它变小的应用程序。

    如果您的应用程序可能会被大量下载,您可能希望对 .NET 的更高版本保持警惕,而您的用户可能还没有这些版本。

    如果像大多数一样,它在可能使用的系统上足够快且足够小,请使用可以让您开发得最快和最好的东西。

    在几乎所有情况下,优化的正确方法是开发人员的努力。使用任何可以最快、最好地完成高质量工作的方法。

    【讨论】:

      【解决方案4】:

      首先..(虽然我是一个顽固的 c++ 编码器)我不得不承认 c# 在大多数情况下在速度和大小方面都非常好。在某些情况下,应用程序更小,因为解释的部分已经在目标系统上。 (不要向我发送垃圾邮件,带有 dll 的应用程序比应用程序更小。Windows 恰好附带了已经存在的“DLL”。)

      至于编码.. 老实说,我认为没有显着差异。我不会花很多时间输入代码。大部分是在思考一个问题。代码部分非常小。在这里和那里保存几行.. Blahh 这对我来说不是一个论点.. 如果是我会在 APL 工作。学习 STL、MFC 和你拥有的东西可能与学习 c# 库一样密集。最后他们都是一样的。

      C# 确实有一件事要做。一个市场。这是最新的“热门”技能,因​​此有市场。工作很容易找到。现在请记住,Java 在几年前是一项“热门”技能,现在汤姆迪克和哈利在他们的简历中都有它。这使得定位自己变得更加困难。

      好的.. 说了这么多.. 我喜欢 C++.. 当我真的需要时,没有什么比弄脏更糟糕的了。当 MFC 库不做这项工作时,我会看看他们坐在什么上面等等等等。它是一种长期的语言,我相信它仍然处于或接近世界上最常用的语言。是的 c++,是的!

      【讨论】:

        【解决方案5】:

        另请注意,大多数 Windows 计算机上已经安装了 .NET,所以这真的不应该是一个问题。

        此外,除了 .NET 安装之外,.NET 应用程序往往非常小。

        对于大多数带有 UI 的应用程序,用户的速度是真正限制时间的因素。

        【讨论】:

          【解决方案6】:

          C# 应用程序的启动速度比 MFC 应用程序慢,但是一旦加载应用程序,您可能不会注意到两者之间的速度差异。

          【讨论】:

          • 确实如此,但 CLR 4 (.NET 4.0) 应该会显着改善 .NET 应用程序的冷启动时间。
          【解决方案7】:

          没有关于您计划开发的应用程序的信息,我投票支持 WPF。

          【讨论】:

            【解决方案8】:

            在我看来,这些要求应该可以帮助您决定平台。更重要的是:拥有一个易于维护的应用程序还是必须非常快速和小型的应用程序?

            现在可以使用 .NET 和托管代码编写大量应用程序,从长远来看,这通常有利于开发。根据我的经验,.NET 应用程序对于大多数用例来说通常足够快,而且它们更易于创建。 原生 C++ 仍有其用途,但只是为了“更快、更小”,当“足够快和足够小”就足够时,这听起来不足以成为理由。

            【讨论】:

              【解决方案9】:

              本机代码和托管代码之间的速度争论在这一点上基本上不是问题。 .NET Framework 的每个版本都比以前的版本提高了性能,并且应用程序性能始终是 .NET 开发团队的重中之重。

              从 Windows Vista 和 Windows Server 2008 开始,.NET Framework 作为操作系统的一部分安装。它也是 Windows Update 的一部分,因此几乎所有 Windows XP 系统都将安装它。如果将框架安装在目标机器上的要求确实是一个很大的问题,那么还有一些编译器基本上会将所需的运行时部分嵌入到您的应用程序中以生成单个 exe,但它们很昂贵(在我看来,不值得花这么多钱)。

              【讨论】:

                【解决方案10】:

                MFC 不难学,其实很简单。

                几乎等于 C#。

                【讨论】:

                • 同意.. 我会说很简单.. 如果需要,您可以更深入地研究。
                • 完全 100% 不同意,我见过的每个 MFC 项目都是一团糟。这确实对工具有影响,而不仅仅是开发人员。
                【解决方案11】:

                语言或工具的选择应取决于您的项目的功能和性能要求以及专业知识。如果性能对您来说是一个真正的考虑因素,并且您已经进行了一些分析以更喜欢 C++ 而不是 C#,那么您已经做出了决定。请注意,尽管拥有基于 MFC 的应用程序也不是非常有效。另一方面,.NET 应用程序的开销被夸大了。

                性能实际上取决于您编写代码的好坏以及存在的可扩展性要求。如果您只需要使用一个最大数据库记录为 1K 的客户端,那么我们不应该谈论性能。

                如果易于开发和可维护性更重要,那么 C# 肯定是首选。

                所以我不确定这个问题是否可以根据您提供的数据作为选择 A 或 B 给出答案。您需要对功能和非功能需求进行分析并做出决定。

                【讨论】:

                  【解决方案12】:

                  另外,如果我使用 C#,那么应用程序将比本机代码慢,并且它需要 .NET 框架才能运行

                  MFC 应用程序需要 MFC dll 才能运行(可能还需要 VC 运行时!),因此可能需要安装它们,或者如果它们是静态链接的,则需要增加 exe 的大小。

                  【讨论】:

                    【解决方案13】:

                    块引用

                    .NET 更易于使用。除非您会因为使用它而失去用户或在代码迁移方面遇到问题,否则您可能应该使用 .NET。速度极不可能成为这个问题。大小可能也没那么重要。

                    【讨论】:

                      【解决方案14】:

                      您更熟悉哪种技术?

                      您提供的信息不包括任何有助于决定的信息。是的,MFC 应用程序往往更小(如果您包括运行时大小,从长远来看这不是一个合适的衡量标准)、响应更快且开发成本更高。那又怎样?

                      【讨论】:

                        猜你喜欢
                        • 2013-01-28
                        • 2012-07-15
                        • 1970-01-01
                        • 2012-08-27
                        • 2010-10-30
                        • 2011-06-19
                        • 1970-01-01
                        • 2023-03-30
                        • 2010-09-12
                        相关资源
                        最近更新 更多