C++ Builder或Visual Studio？

Question

我拥有一家软件开发公司。我们为其他公司开发软件，并在他们的名字/标题下进行品牌推广。我们在会计/ERP市场上也有几个自己的品牌。我们的会计软件大约占据了我们业务的60％，并使用C ++ Builder编写。

知道的人都知道，C ++ Builder从Borland到CodeGear再到Embarcadero手中交接过程非常曲折，可能在其中转手了几次。 C ++ Builder已经多次捣鬼了我们的会计软件。QuickReports非常容易出现错误，他们的XML构建描述与GUI没有紧密耦合，导致构建失败--通常界面会出现问题。

在过去的8年中，我们逐渐淘汰了对VCL和错误组件的依赖，但是某些第三方VCL组件仍然不容易被替换。我们使用了来自Developer Express的GRID包-非常好的产品。

我已经到了一个十字路口，在考虑是否购买市场上最新版本的C ++ Builder XE时我很难找到理由，因为当你看到这款产品的糟糕历史时，就会感到困惑。

所以我正在寻求建议或步骤，是否有其他人遇到类似情况并成功切换到Visual Studio的经验？

我们已经慢慢将大多数应用程序迁移到了wxWidgets，除了Developer Express工具。我们还编写了自己的TSQL抽象层，也可以进行移植。

有什么想法或建议吗？您是否已将项目移到Visual Studio上，或者是否尝试过新的Builder XE，并发现它以前的一些缺点现在已经消失？

寻求“曾经走过这条路”的建议。

- Eric

---

请到 programmers.stackexchange.com 上提问。 - casablanca

我理解你的痛苦。我正在考虑使用C++/CLI将遗留的C++代码进行封装，并使用C#和WPF作为前端，以消除对VCL和RAD Studio的依赖。不过，我可能会发布一个新的扩展来了解社区的意见。 - Seth

大约七年后，你做了什么？ - SQLMason

转向 Delphi。它总是比 cppbuilder 更为时新。 - Gabriel

Answer 1

Visual Studio并不适用于与C++ Builder进行比较。

虽然它们都是C++编译器，但：

1. 只有使用.NET语言时，Visual Studio才是RAD的
2. MFC是“半RAD”，但与VCL的易用性相去甚远
3. Visual Studio编译器在生成优化代码方面更胜一筹，但C++ Builder使用Clang也很好
4. Visual Studio和C++Builder都符合标准（CB使用基于Clang的编译器）
5. C++ Builder附带Boost库
6. C++ Builder XE比以前的版本好得多（不包括Builder C++ 6.0）
7. 对于C++开发，您无法击败C++ Builder中的RAD工具，没有任何东西能够接近

编译器之间的差异对于非VCL依赖代码可能不会造成太大影响。我有一个DLL，在VC6、VS2008和Builder 2010/XE下为客户编译。我不得不投入一些#ifdef，但其中大多数实际上是针对VC6的。

我能给出的最大建议是不要转移到MFC，那里就会有痛苦开始。

考虑开发人员的培训。在学习新编译器的特异性时，开发人员将变得明显缓慢，难以生产有效代码。

话虽如此，但当我在为客户选择VS2008/2010或Builder C++进行新产品开发时，我还是选择了Builder，仅因为RAD IDE。

祝您好运。

更新C++ Builder 10.2（2017）：

1. 32位和64位Windows都使用Clang / LLVM（iOS和Android也是如此）
2. 32位和64位Windows都使用Boost 1.55
3. 10.2非常稳定，每个版本都更好

这仍然出现在Google搜索中，因此针对Berlin 10.1再次进行更新：

1. 32位和64位代码现在都在Windows上使用CLANG / LLVM
2. OS X的32位代码仍使用旧编译器
3. Android和iOS编译使用CLANG/LLVM

- Gregor Brandt

---

谢谢，有一些好的评论。正如我所提到的（可能不是很清楚），我处于一个十字路口，在那里我们可以承担切换IDE和消耗学习曲线的成本。我们不使用boost、STL或任何直接使用C++构造之外的东西，当然还有VCL。我们发现一些VCL控件在wxWidgets中没有相应的替代品，这是我们需要解决的另一个痛点。 - Eric

我们已经轻松地从C++ Builder转移到了C#。我们在C++ Builder中使用的大多数VCL控件在.NET中都有相应的同一供应商的控件。我记得当我转向C#时，我发现它是C++ Builder的自然延续。我多年来一直想要的功能（语言、IDE、框架）终于在C#中得以实现！ - Zach Saw

此外，C++Builder 64位现在使用clang后端，因此从现在开始它的定点数已经被修复为3、4。不幸的是，32位目标仍然使用旧的、糟糕的编译器。 - M.M

Answer 2

转向wxWidgets有其优点之一是您不会受到像C++ Builder或Visual Studio这样的IDE的束缚。 C ++ Builder存在许多问题，其主要优势是VCL框架，我认为它仍然是C ++中最好的GUI框架之一。 问题当然在于它需要C ++ Builder，而它在稳定性和编译器性能方面确实存在一些问题。

然而，Visual Studio并不是终极IDE，最新版本充其量也有缺陷，并且C ++ Builder提供的许多RAD工具在Visual C ++中根本不存在（除非您愿意使用.NET语言）。

我可以完全理解您希望使您的代码不再依赖C ++ Builder的愿望，说实话，我自己也怀疑它是否会持续存在很久。但是从您的帖子听起来，您的大部分开发确实依赖于快速开发的应用程序，在C ++宇宙中，C ++ Builder是满足此特定要求的最佳工具之一。

就个人而言，我从未真正认为C ++是快速开发Windows GUI应用程序的最佳解决方案，也许您的重点不应该放在寻找不同的IDE上，而是寻找更适合的语言，我建议使用Delphi，通过使用Delphi，您将能够编译现有的C ++ Builder项目，甚至重用现有的VCL组件。

Delphi - 我相信 - 将比C ++ Builder存在更长时间，无论是以Delphi的形式还是以Lazarus（freepascal的IDE）的形式，它甚至是跨平台的，并支持64位开发。

如果换一种语言不是选项，则暂时继续使用C ++ Builder，但不要升级到XE版本，我认为这个价格标签是不合理的。（当然，前提是您已经在相对新的版本上工作）。

- Tommy Andersen

---

倾向于同意大多数评论。然而，转换语言并不是一个选项。我们都不知道 obj-Pascal，我也不关心。我们有一些底层驱动程序的东西，我担心在 Delphi 中复制这些代码会是一场噩梦。而且 Delphi 是同一公司的产品，所以我不确定它能为我带来什么好处。 - Eric

在大多数情况下，驱动程序和图形界面不必使用相同的语言编写，事实上通常不会。Delphi是Embarcardero产品是正确的，但这为您提供了保留现有库的机会。此外，您可以选择切换到Free Pascal。还有一件事，从使用VCL的C++切换到Delphi并不困难。VCL是用obj. pascal编写的。 - Tommy Andersen

不要忘记wxWidgets也不是完美的 - 例如，如果本地用户体验很重要，C++Builder具有本地控件。这个问题非常古老（2010年），自那时以来就有了FMX（跨平台，也有本地控件）、基于Clang的编译器适用于许多平台，包括Win32和Win64等等。就RAD而言，我认为没有什么可以与之竞争，当然在VC++方面也是如此。 - David

Answer 3

如果你一直使用C++并希望在Visual Studio中使用与RAD Studio提供的相同类型的IDE，则会感到震惊。

说实话，C++Builder从来没有成为一款对于C++而言不好的GUI开发环境。它可能是有史以来最好的C++环境。为什么？因为你可以利用所有优秀的Delphi组件。

在Visual Studio中，没有可替代ExpressQuantumGrid™ Suite用于C++。

大多数关于C++Builder的严重抱怨通常集中于其对STL和Boost等标准的兼容性上。

我认为Embarcadero不会放弃支持C++Builder。问题通常在于Delphi团队（第三方）编写代码的方式。说实话，我只记得DevExpress的其中一个版本出了问题。

简短明了：如果你想要使用C++和某种RAD/GUI工具，请坚持使用C++Builder。

- weirdo12

Answer 4

我们一年前从C++Builder 6 升级到XE，非常满意XE。移植到UnicodeString并不太困难。我们还将所有的BDE代码转换为BDExpress (DBX)。这需要很长时间和大量的重写，但收获颇丰。 需要记住的是，两者都不完美。正如谚语所说，“草皮总是在篱笆的另一边看起来更绿。” 如果您想要开发效率，使用C++Builder和VCL。 如果您想要长期安全性或轻松找到程序员，则使用Visual Studio。 我的观点是：保留您喜欢的部分，并替换您不喜欢的部分。例如，保留C++Builder并替换QuickReport。 顺便说一下，如果您已经做出决定，请告诉我们。

- Stephane

Answer 5

我是C++ Builder的产品经理。

C++ Builder有一些特点：

• 它非常适合UI设计。可以使用VCL（本地Windows控件）或FMX（跨平台，如果需要也可以使用本地控件）。Visual C++无法媲美，而MFC仍然以1995年的方式设计UI。

• 它专注于跨平台。Visual C++正在推广这一点，但是C++Builder提供了“全套解决方案”：不仅编译，还包括完整的库、UI等。VC++在需要其他东西时就无法实现跨平台。

• 它被许多需要数据库工作或其他“企业级”项目的人广泛使用，主要是因为数据库库（FireDAC）的架构非常好，并支持许多数据库。

• 除了macOS，它在所有平台上都使用Clang。它也在朝着更新到C++17的方向发展。

• 它具有Live Preview等功能（设计应用程序，将应用程序实时显示在插入设备（如手机）上），这些功能似乎在某些最近的微软功能中得到了很大的启发；）不要担心，Visual Studio，我们爱你:)因此，在许多领域，它实际上是领先的，特别是对于跨平台开发。

缺点：

• IDE仅在Windows上运行。您可以在任何地方部署并在任何设备上调试，但IDE是Windows。

• 它只支持C++11，虽然正在朝着C++17的方向发展。MacOS是（惊叹）C++98。这在路线图上。您可以依赖它及时更新。

• 代码完成和代码洞察力比Visual C++弱。正在努力改进。

• 它有一个作为错误的声誉，最近发布的版本正在积极解决这个问题，而且我个人也在努力消除这个问题。但是声誉很难摆脱。

- David

---

经过一年的时间，代码完成、文档编写和代码洞察力在Tokyo 10.2.3中仍未得到改善。现在使用C++ Builder IDE仍然很痛苦。 - Yami Odymel

试用版C++ Builder 10.3.2，VCL项目，代码补全仅适用于"Classic编译器"，"Classic"编译器仅支持C++98。 - Mosolov Sergey

Answer 6

我们正在缓慢地转向VS2008和wxWidgets。对于每个可以在C++ Builder中购买的组件（Developer Express等），我们计划聘请某人为我们构建该部分，或者聘请组件制造商为我们构建一个wxWidget组件。目前来说，C++ Builder是在Windows上进行可视化编程的最佳方式。然而，它没有x64位支持，也不支持Mac和Linux。据说他们将会构建一个跨平台版本...我们需要等多久呢？

- pcunite

---

有趣，很好奇听到你们的成功和面临的问题，以及你们如何解决这些问题。自从我发了这篇文章以来，我们在使用wxWidgets方面取得了更多进展。我已经在VS和CBuilder下运行了wxWidgets。就生产力而言，WxWidgets GUI构建器并不是很好。在CBuilder中，我可以双击GUI元素（TButton），然后它就会带我直接进入代码。但在WxWidgets世界中并非如此...这是我对开发工具不太深思熟虑的抱怨。 - Eric

XE5已支持64位。 - Gregor Brandt

Answer 7

Most answers here mix compilers, IDEs, and libraries (and the question has an important subtext: how to choose an environment for business/GUI applications). The question and answers mix Visual Studio languages and project types: C++ with poor support for GUI, C# with a wonderful ecosystem, etc. (Basic, F# etc.) all under the Visual Studio umbrella.

GUI libraries:

MFC is a library that is quite ancient and low productive. It's a low-level wrapper over *.RES and WM_Envents. It probably still cannot be compiled without MS C++ (and maybe the license prohibits this).

VCL is the most important library to Borland/Embarcadero philosophy and market share in one area: building GUI applications. It seems to be a good idea to use portable open-source GUI libraries, but almost all of them have not-so-good support in clickable IDEs.

IDE:

Personal feeling seems to be the best answer. Agree, only the producer IDE has optimal control over its own GUI components. Many independent IDEs are cited here, I will be short.

Compiler:

Borland C++ compiler was far from C++ standards for many years (couldn't compile mainstream C++ code like boost). I believe many goals are contradictory: coexistence with Object Pascal code or C++ standards.

说实话：大多数来自C++ Builder世界的项目不需要使用像boost和类似的高级“黑客”代码，个人认为Borland / Embecareo C ++语言是一种独立的语言，部分基于C ++（部分基于VCL）。总的来说，这个世界越来越封闭，没有驱动程序，没有兼容的库，没有现代网络协议等等。

我的观点是：MS C++编译器（过去和现在）更好地支持标准。

我曾经是（可能很好的）Borland C++程序员。现在我使用C#/WinForms Visual Studio（有时候很少用Java SWT或Swing）和Microsoft C++来处理低容量的C/C++非GUI项目。

最后的话：你是否限制于C++语法，还是可以切换？如果可以，切换到C#。如果必须是C++和高生产力GUI，则向Embecadero支付（越来越多的）费用。

- Jacek Cz

Answer 8

就像@casablanca所说的那样，但你也应该考虑非常好的替代方案，如果你说你对现在使用的程序不满意：

1. Eclipse (CDT)：非常好且完整的产品
2. NetBeans：经常与eclipse相比较
3. Code::Blocks：更简单，但经常被推荐，我认为它的构建系统集成不是很好，但与wxWidgets紧密集成
4. QtCreator：我个人最喜欢的（干净快速且可以使用git），但目前仅用于个人项目和小型应用程序，可能不适合wxWidgets，尽管我也不使用Qt :)

一个警告：Visual Studio调试器被认为是“最好的”，但你需要付费。上述1-4都是免费的，并且备受好评。

- rubenvb

---

Visual Studio Express（包括调试器）现在是免费的，您可以使用它来开发商业产品。对于Java来说，Eclipse还不错，但在我看来，与Visual Studio相比，它和C++之间没有可比性。 - Stuart Golodetz

我应该说，就IDE而言，成本并不是阻碍。换句话说，我可以承担升级到Builder XE或切换到VS的成本，但真正需要考虑的是长期路线图方面的合理性。我一直在使用XE的演示版本，虽然我看到了重大改进，但仍然存在一些旧的问题！我正在努力决定是否花时间去学习VS（或其他东西），还是找出另一组处理Builder XE错误的怪癖。 - Eric

我非常讨厌Eclipse。它是一个Java应用程序，我认为这就是它表现迟缓的原因。我需要一个没有任何延迟的IDE。我和我的开发人员都打字速度很快，并且我们都定制我们的IDE以实现快速文件保存、编译等等... 对于我们来说，Eclipse并不适用。我很久以前看过Code::Blocks，但当时它似乎还不成熟。我可能会花费几个小时重新审查它，但我目前在WxWidgets上的时间投资似乎很有前途，除了他们没有像CBuilder一样好的GUI设计师或集成工具链这一事实之外。 - Eric

Answer 9

我曾在C++ builder 2006、2009、XE6和RS10中工作过。建议将您的项目转换出来，因为多年来我遇到了许多问题，比如环境崩溃和其他奇怪的行为。此外，如果您需要帮助，用户社区几乎不存在，所以通常必须等待24小时并希望Remy回复您:) 或者尝试阅读Delphi代码并将其翻译成C++（是的，他们的Delphi环境更受欢迎...没有像面向对象的Pascal那样的东西...）。无论将其转换为什么环境，它可能都不会像您想象的那样干净或容易。因此，考虑到会有很多工作，建议考虑您的长期策略。

我个人建议，如果需要桌面应用程序，迁移到Java并使用SWT（https://www.eclipse.org/swt/）。我还建议坚持使用友好许可证的开源库，这样您就不必担心每年支付费用，并且可以扩展业务。如果您不需要客户端系统，则仍然建议使用Java，因为它可以完成全栈工作，非常强大。从我的经验来看，Java社区往往有更聪明（大多数情况下）且回答干净利落的人。我见过一些使用.Net的hackish东西 :)

您提到了Visual Studio，如果您无法使用Java，则我建议C#作为下一个最佳选择。但是，您仍然需要向Microsoft支付许可证费用，并处理用户组。

- James Oravec

Answer 10

我开始从事Windows的C++客户端工程师。我同意有关MFC相当糟糕的评论。在我的几个项目中，我们使用基于XML模板的自己编写的UI引擎，而不是使用MFC，这样图形设计师就可以在不需要软件工程师的情况下玩弄UI。

在我个人看来，C#.Net是Windows UI开发的最佳选择。IDE非常出色。用C++编写UI需要太多的努力。您仍然可以保留需要高性能的C++部分。

附注：刚刚注意到VCL维基页面上的这一点。“.NET是以VCL为模型的，因为第一个Delphi版本的主要架构师之一Anders Heijlsberg去了微软，并成为了.NET的主要架构师之一”

- expert