C++ Builder 或 Visual Studio

C++ Builder or Visual Studio

提问by Eric

I own a software development company. We develop software for other companies who brand under their name/titles. And we also have a couple self branded titles in the Accounting/ERP market. Our accounting software is roughly 60% of our business and written in C++ Builder.

我拥有一家软件开发公司。我们为其他以其名称/头衔进行品牌推广的公司开发软件。我们在会计/ERP 市场上也有几个自有品牌的产品。我们的会计软件约占我们业务的 60%，是用 C++ Builder 编写的。

Those who know, realize C++ Builder has had a very rocky road in changing hands from Borland, to CodeGear, to Embarcadero and possibly a few times in between. C++ Builder has screwed us a number of times on our accounting software. The QuickReports was notoriously buggy, Their XML build description is not tightly coupled to the GUI causing builds to not work -- generally buggy interface.

知道的人会意识到 C++ Builder 在从 Borland 到 CodeGear、到 Embarcadero 的易手过程中经历了非常艰难的过程，并且可能在这之间发生了几次。C++ Builder 在我们的会计软件上多次欺骗我们。QuickReports 是出了名的错误，他们的 XML 构建描述与 GUI 没有紧密耦合，导致构建无法工作——通常是有错误的界面。

Over the past 8 years we've steadily made inroads to remove our reliance on the VCL and buggy components however, some 3rd party VCL components are just not easily replaceable still. We use a GRID package from Developer Express - great product.

在过去的 8 年里，我们一直在稳步取得进展，以消除我们对 VCL 和错误组件的依赖，但是，一些 3rd 方 VCL 组件仍然不容易更换。我们使用 Developer Express 的 GRID 包 - 很棒的产品。

I'm just about at a crossroads and with the latest version of C++ Builder XE on the market I'm having a hard time justifying the price when you look at the crappy history of this product.

我正处于十字路口，而且市场上有最新版本的 C++ Builder XE，当您查看该产品糟糕的历史时，我很难证明价格合理。

So I'm looking for advice or steps anyone else followed who might be in similar situation and successfully made the switch to Visual Studio.

因此，我正在寻找可能处于类似情况并成功切换到 Visual Studio 的其他人遵循的建议或步骤。

We've slowly moved most of our application to wxWidgets except for the Developer Express tools. And we've written our own TSQL abstraction we can port as well.

除了Developer Express 工具之外，我们已经慢慢地将大部分应用程序移至wxWidgets。我们已经编写了我们自己的 TSQL 抽象，我们也可以移植。

Any thoughts or suggestions? Have you moved your project to Visual Studio or have you played around with the new Builder XE to find many of its previous shortcomings now gone?

有什么想法或建议吗？您是否将您的项目转移到 Visual Studio 或您是否使用过新的 Builder XE 以发现它以前的许多缺点现在都消失了？

Looking for "been there, done that" advice.

寻找“去过那里，做过那件事”的建议。

采纳答案by Tommy Andersen

Moving to wxWidgets has its advantages one of them being that you will not be bound to an IDE like C++Builder or Visual Studio. C++ Builder has had several problems, its main strength being the VCL framework, which in my oppinion is still among the best GUI frameworks around for C++. The problem ofcourse being that it requires C++ Builder, which to put it mildly does have some problems with stability and compiler performance.

迁移到 wxWidgets 有其优势之一，即您不会被绑定到像 C++Builder 或 Visual Studio 这样的 IDE。C++ Builder 有几个问题，它的主要优势是 VCL 框架，在我看来，它仍然是 C++ 最好的 GUI 框架之一。问题当然是它需要 C++ Builder，说得客气一点，确实在稳定性和编译器性能方面存在一些问题。

However Visual Studio is not the ultimate IDE, the latest version is at best buggy, and many of the RAD tools you're given by C++ Builder simply do not exist in Visual C++ (unless you are willing to go for the .net languages).

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

I can perfectly well understand your wish to make your code less dependant on C++ Builder, to tell you the truth I kind of doubt it will continue to be around for long myself. However from what it sounds like in your post, most of your development really relies on rapid developed applications, and in the C++ universe C++ Builder is one of the best tools around for this particular requirement.

我完全可以理解您希望让您的代码减少对 C++ Builder 的依赖，说实话，我有点怀疑它是否会继续存在很长时间。然而，从您的帖子中听起来，您的大部分开发实际上都依赖于快速开发的应用程序，而在 C++ 领域，C++ Builder 是满足这一特定要求的最佳工具之一。

Personally I never really thought of C++ as the best solution for Rapid Developed Windows GUI Applications, perhaps your focus shouldn't be on finding a different IDE, but on finding a more appropriate language, I would suggest Delphi, by using Delphi you will be able to compile you're existing c++ builder projects, and even reuse your existing VCL components.

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

Delphi will - I trust - be around for longer than C++ Builder, either in the form of Delphi, or in the form of Lazarus (IDE for freepascal) which is even cross platform and gives support for 64 bit development.

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

If however a change of language is not an option, I would stick with C++ Builder for now, but not upgrading to the XE version, which I simply do not think is justified by the price tag. (Given ofcourse you already work on a relatively new version).

但是，如果不能选择更改语言，我现在会坚持使用 C++ Builder，但不会升级到 XE 版本，我只是认为价格标签不合理。（当然，您已经在开发一个相对较新的版本）。

回答by Gregor Brandt

Visual Studio is not really comparable to C++ Builder.

Visual Studio 不能与 C++ Builder 相提并论。

Yes they are both C++ compilers but:

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

1. Visual Studio is only RAD when using .NET languages
2. MFC is 'semi-rad' but does not come close to ease of use of VCL
3. Visual Studio compiler is better at producing optimized code, but C++ Builder uses Clang which is pretty good
4. Visual Studio and C++Builder are both standards compliant (CB using Clang-based compilers)
5. C++ Builder comes with Boost
6. C++ Builder XE is much better than previous versions (not including Builder C++ 6.0)
7. You can't beat the RAD tools in C++ Builder for C++ development, nothing comes close

1. Visual Studio 在使用 .NET 语言时只是 RAD
2. MFC 是 'semi-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++ Builder 中用于 C++ 开发的 RAD 工具，没有什么比这更接近的了

The differences in compilers probably won't hurt you too much for non VCL dependent code. I have a DLL that I compile for clients under VC6, VS2008 and Builder 2010/XE. I have had to toss in a few #ifdefs, but most of them are actually for VC6.

对于非 VCL 依赖代码，编译器的差异可能不会对您造成太大伤害。我有一个为 VC6、VS2008 和 Builder 2010/XE 下的客户端编译的 DLL。我不得不加入一些#ifdefs，但其中大部分实际上是针对 VC6 的。

The biggest recommendation I can make is DO NOT MOVE TO MFC, thats where the pain starts.

我能提出的最大建议是不要搬到 MFC，那是痛苦开始的地方。

Think about the training for developers as well. Your developers will become significantly slower at producing working code while learning the idiosyncrasies of a new compiler.

还要考虑对开发人员的培训。在学习新编译器的特性时，您的开发人员在生成工作代码时会明显变慢。

With all that said, when I was given a choice for a client between moving to VS2008/2010 or Builder C++ for a new product, I picked Builder, just for the RAD IDE.

话虽如此，当我在为新产品迁移到 VS2008/2010 或 Builder C++ 之间选择客户端时，我选择了 Builder，仅用于 RAD IDE。

Good luck.

祝你好运。

Updated for C++Builder 10.2 (2017):

为 C++Builder 10.2 (2017) 更新：

1. 32 bit and 64 bit Windows both use Clang/LLVM (as do iOS and Android)
2. 32 bit and 64 bit Windows both use Boost 1.55
3. 10.2 is very stable, getting better every release

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

This still comes up on Google searches, so updated again for Berlin 10.1:

这仍然会出现在 Google 搜索中，因此针对柏林 10.1 再次更新：

1. 32 bit and 64 bit code now uses CLANG/LLVM for Windows
2. 32 bit code for OS X still uses old compiler
3. Android and iOS compiles use CLANG/LLVM

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

回答by weirdo12

If you are sticking with C++ and expect the same kind of IDE in Visual Studio for C++ that RAD Studio provides you'll be shocked.

如果您坚持使用 C++ 并期望在 Visual Studio for C++ 中使用 RAD Studio 提供的相同类型的 IDE，您会感到震惊。

To be honest, C++Builder has never been a bad GUI development environment for C++. It's likely the best the has ever been for C++. Why? Because you can take advantage of all the great Delphi components.

老实说，C++Builder 从来都不是 C++ 糟糕的 GUI 开发环境。它可能是 C++ 有史以来最好的。为什么？因为您可以利用所有出色的 Delphi 组件。

There is no substitute for ExpressQuantumGrid? Suite for C++ in Visual Studio.

ExpressQuantumGrid 没有替代品吗？Visual Studio 中的 C++ 套件。

Most of the serious complaints about C++Builder have been often centred on it's compliance with standards like the the STL and Boost.

大多数关于 C++Builder 的严重抱怨通常集中在它是否符合 STL 和 Boost 等标准。

I don't think that Embarcadero will give up on supporting C++Builder. The issues have usually been with the way the Delphi guys (3rd party) have coded stuff. Honestly I only recall one release of DevExpress's stuff being an issue.

我认为 Embarcadero 不会放弃支持 C++Builder。问题通常与 Delphi 人员（第 3 方）编码内容的方式有关。老实说，我只记得 DevExpress 的一个版本是一个问题。

Short and sweet: if you want to use C++ and some sort of RAD/GUI thing stick with C++Builder.

简短而甜蜜：如果你想使用 C++ 和某种 RAD/GUI 的东西，请坚持使用 C++Builder。

回答by Stephane

We upgraded from C++Builder 6 to XE a year ago. Very happy with XE. The move to UnicodeString was not too difficult. We also converted all our BDE code to BDExpress (DBX). That took a long time and lots of re-write, but was well worth it. The thing to remember is that neither is perfect. As the saying goes, The grass always looks greener on the other side of the fence. If you want development efficiency, use C++Builder and the VCL. If you want very long term security, or easily find programmers, then Visual Studio. My opinion: Keep what you like and replace what you don't. For example, keep C++Builder and replace QuickReport. BTW, if you've made a decision, please let us know.

我们在一年前从 C++Builder 6 升级到 XE。对 XE 非常满意。转向 UnicodeString 并不太困难。我们还将所有 BDE 代码转换为 BDExpress (DBX)。这花了很长时间和大量的重写，但非常值得。需要记住的是，两者都不是完美的。俗话说，篱笆另一边的草总是显得更绿。如果要开发效率，请使用 C++Builder 和 VCL。如果您想要非常长期的安全性，或者很容易找到程序员，那么 Visual Studio。我的观点：保留你喜欢的，替换你不喜欢的。例如，保留 C++Builder 并替换 QuickReport。顺便说一句，如果您已做出决定，请告诉我们。

回答by David

C++ Builder PM here.

C++ Builder PM在这里。

C++ Builder has some specific strengths:

C++ Builder 有一些特定的优势：

• It is great for UI design. Either with the VCL (native Windows controls) or FMX (cross-platform, often native controls too if you need). Visual C++ doesn't come anywhere near, and MFC is still designing UIs the way you did in 1995.

• It's focused on cross-platform. Visual C++ is advertising it, but C++Builder provides the 'full stack': not just compiling, but full libraries, UI, everything. VC++ is cross-platform until you need something that isn't.

• It's widely used by people needing database work, or other "enterprise"y items, mostly because the database libraries (FireDAC) are very nicely architected and support a lot of databases.

• It uses Clang for all platforms apart form macOS, which still has an old compiler. It's also heading towards updating to C++17.

• It has features like Live Preview (design your app, see the app live on a plugged-in device like your phone) which seem to have heavily inspired certain recent MS features ;) Don't worry, Visual Studio, we love you :) So in many areas it actually leads, especially for x-plat development.

• 它非常适合 UI 设计。使用 VCL（本机 Windows 控件）或 FMX（跨平台，如果需要，通常也是本机控件）。Visual C++ 离我们不远，而且 MFC 仍在按照您在 1995 年的方式设计 UI。

• 它专注于跨平台。Visual C++ 正在宣传它，但 C++Builder 提供了“完整的堆栈”：不仅是编译，还有完整的库、UI 等等。VC++ 是跨平台的，除非您需要一些不需要的东西。

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

• 它在所有平台上使用 Clang，除了 macOS，它仍然有一个旧的编译器。它还朝着更新到 C++17 的方向发展。

• 它具有诸如实时预览（设计您的应用程序，在诸如您的手机之类的插入式设备上实时查看应用程序）之类的功能，这些功能似乎极大地激发了某些最近的 MS 功能；）别担心，Visual Studio，我们爱您 :)所以在许多领域它实际上处于领先地位，尤其是在 x-plat 开发方面。

Weaknesses:

弱点：

• The IDE only runs on Windows. You can deploy anywhere and debug on anything, but the IDE is Windows.

• It's C++11 only, although heading towards C++17. MacOS is (gasp) C++98. It's on the roadmap. You can rely on it being up to date in time.

• Code completion and code insight are weaker than Visual C++. Working on it.

• It has a reputation as buggy, which is something actively being worked on in recent releases and a personal drive of mine to eliminate. But a reputation is hard to shed.

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

• 它只是 C++11，虽然朝着 C++17 前进。MacOS 是（喘气）C++98。它在路线图上。您可以相信它会及时更新。

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

• 它以 buggy 着称，这是最近版本中正在积极研究的东西，也是我个人消除的动力。但名声是很难摆脱的。

回答by pcunite

We are in a slow move to VS2008 and wxWidgets. For every component that can be purchased for C++ Builder (Developer Express, etc) our plans are to hiresomeone to build that one pieceor hire the component maker to builda wxWidget component for us.

我们正在缓慢地迁移到 VS2008 和 wxWidgets。对于可对于C ++ Builder（Developer Express公司等），我们的计划购买每一个部件都聘请某人来构建一个片或租用的组件制造商，以建立一个wxWidget组件我们。

C++ Builder is the best way to program visually on windows at the moment though. However, no x64bit support and no mac, linux support. Supposedly they are going to build a crossx version... how long can we wait?

不过，C++ Builder 是目前在 Windows 上进行可视化编程的最佳方式。但是，没有 x64bit 支持，也没有 mac、linux 支持。据说他们要建立一个crossx版本……我们能等多久？

回答by expert

I've started as C++ client-side engineer for Windows. I agree with comment about that MFC is pretty bad. In several of my projects we've written our own UI engines with XML-driven templates instead of using MFC so graphic designers can play with UI without need of software engineers.

我已经开始担任 Windows 的 C++ 客户端工程师。我同意关于 MFC 非常糟糕的评论。在我的几个项目中，我们使用 XML 驱动的模板编写了自己的 UI 引擎，而不是使用 MFC，因此图形设计师可以在不需要软件工程师的情况下使用 UI。

In my personal opinion C#.Net is the best for Windows UI development. IDE is great. Coding UI in C++ requires way too much effort. You can still keep pieces of C++ that require high performance.

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

PS. Just noticed this on wiki page for VCL. ".NET is modeled after VCL, since one of the main architects of the first Delphi versions, Anders Heijlsberg, went to Microsoft and was one of the main architects of NET there"

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

回答by Jacek Cz

Most answers here mixcompilers, IDE and library (and question has important subtext: how to choose environment for business/GUI applications). Question and answers mix Visual Studio languages and project types: C++ with poor support to GUI, C# with wonderful ecosystem etc... (Basic, F# etc) all under Visual Studio umbrella.

这里的大多数答案都混合了编译器、IDE 和库（并且问题具有重要的潜台词：如何为业务/GUI 应用程序选择环境）。问题和答案混合了 Visual Studio 语言和项目类型：C++ 对 GUI 的支持很差，C# 具有出色的生态系统等......（基本、F# 等）都在 Visual Studio 的保护伞下。

GUI libraries:

图形用户界面库：

MFC is library, really quite ancient and low productive. Its low level wrapper over *.RES and WM_Envents. Probably still cannot be compiled without MS C++ (and maybe licence prohibit this)

MFC 是图书馆，真的很古老而且效率很低。它对 *.RES 和 WM_Envents 的低级包装。没有 MS C++ 可能仍然无法编译（也许许可证禁止这样做）

VCL is library most important to Borland/Enbecaro philosophy and market share in one area: build GUI applications. Seems be good use portable opensurce GUI libraries, but almost all have not so good support in clickable IDE

VCL 是一个对 Borland/Enbecaro 哲学和市场份额最重要的库：构建 GUI 应用程序。似乎可以很好地使用可移植的 opensurce GUI 库，但几乎所有的可点击 IDE 都没有很好的支持

IDE:

IDE：

Personal feeling seems best answer. Agree, only producer IDE has optimal constrol over own GUI compoments. Many independent IDE is cited here, I will be short.

个人感觉似乎是最好的答案。同意，只有生产者 IDE 才能对自己的 GUI 组件进行最佳控制。这里引用了很多独立的IDE，我就不多说了。

Compiler:

编译器：

Brland C++ compiler many year was far from c++ standards (cant compile main stream c++ code like boost). I believe many goals are contradictory: coexistence with Object Pascal code or C++ standards.

Brland C++ 编译器很多年都离 C++ 标准很远（无法编译像 boost 这样的主流 C++ 代码）。我相信许多目标是相互矛盾的：与 Object Pascal 代码或 C++ 标准共存。

To tell the true: most project from C++ Builder worlds don't require to use highly "hackers" code like boost and similar, personally I treat Borland/Embecareo C++ language as independent language partially based on C++ (partially on VCL). General this world is closed (more and more), no drivers, no compatible libraries, no modern network protocols etc.

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

My opinion: MS C++ compilers (in the past and now) better support standards.

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

I was (maybe good) Borland C++ programmer. Now I use C#/WinForms Visual Studio (sometimes, rare Java SWT or Swing) and Microsoft C++ to low volume C/C++ non-GUI projects

我是（也许不错）Borland C++ 程序员。现在我使用 C#/WinForms Visual Studio（有时，很少使用 Java SWT 或 Swing）和 Microsoft C++ 来处理小批量 C/C++ 非 GUI 项目

Final words: are You limited to C++ syntax, or can switch? I yes, switch to C#. If must be C++ and high productive GUI, pay (more and more) to Embecadero

最后的话：您是否仅限于 C++ 语法，或者可以切换？我是的，切换到 C#。如果必须是 C++ 和高生产力的 GUI，支付（越来越多）Embecadero

回答by James Oravec

I've worked in C++ builder 2006, 2009, XE6 and RS10.

我曾在 C++ builder 2006、2009、XE6 和 RS10 中工作过。

I would recommend converting your projects out of it. I've had numerous issues over many years, such as the environment crashing and many other quirky behavior. Furthermore, if you do need help with something, the user community is next to non existent, so you normally have to wait 24 hours and hope that Remy responds to you :) Or try to read through delphi code and translate it to C++ (yes their delphi environment is more popular... nothing like object oriented pascal...).

我建议将您的项目转换为它。多年来，我遇到了许多问题，例如环境崩溃和许多其他古怪的行为。此外，如果您确实需要帮助，用户社区几乎不存在，因此您通常必须等待 24 小时并希望 Remy 回复您:) 或者尝试通读 delphi 代码并将其翻译成 C++（是的他们的 delphi 环境更受欢迎……完全不像面向对象的 pascal ……）。

No matter what environment you convert it to, it probably won't be as clean or as easy as you'd like it. So knowing there would be a lot of work, so I suggest looking at your long term strategy.

无论您将其转换到什么环境，它都可能不会像您希望的那样干净或容易。所以知道会有很多工作，所以我建议看看你的长期战略。

I personally would recommend migrating to java and using SWT (https://www.eclipse.org/swt/), if you need a desktop application. I would also recommend sticking to open source libraries with friendly licenses, so you don't have to worry about paying money every year and allows you to scale your business. If you don't need a client system, then I would still recommend java, as it does the full stack and is very powerful. The java community from my experience tends to have sharper people (for the most part) with clean answers. I've seen a bunch of hackish things that use .Net :)

如果您需要桌面应用程序，我个人建议迁移到 Java 并使用 SWT ( https://www.eclipse.org/swt/)。我还建议坚持使用具有友好许可证的开源库，这样您就不必担心每年都要付钱并允许您扩展业务。如果您不需要客户端系统，那么我仍然会推荐 java，因为它具有完整的堆栈并且非常强大。根据我的经验，Java 社区往往有更敏锐的人（在大多数情况下），他们的答案很清晰。我见过一堆使用 .Net 的骇人听闻的东西 :)

You did mention Visual Studio, if you can't do java, then I would recommend C# as your next best alternative. But then you still have to pay MicroSoft for licenses, and also deal with the user group.

你确实提到了 Visual Studio，如果你不会做 java，那么我会推荐 C# 作为你的下一个最佳选择。但是，您仍然需要向 MicroSoft 支付许可证费用，并且还要与用户组打交道。

回答by Remy Lebeau

I hate to say this, but my own company is at this same cross-roads. We have been using C++Builder for many years (never upgraded beyond v6), and our management people have recently pulled the trigger to make the switch to Visual Studio moving forward :-( I do not think we will be porting our existing C++Builder apps to VC++ anytime soon, as that would be a major re-write, but our new products in the future will be in VC++/.NET now.

我不想这么说，但我自己的公司也处于同样的十字路口。我们多年来一直在使用 C++Builder（从未升级到 v6 以上），我们的管理人员最近扣动了扳机，以向前推进到 Visual Studio 的切换:-( 我认为我们不会移植我们现有的 C ++Builder 应用程序很快就会转为 VC++，因为这将是一次重大的重写，但我们未来的新产品现在将在 VC++/.NET 中。