C++ Builder or Visual Studio

Question

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.

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.

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.

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.

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.

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.

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?

Looking for "been there, done that" advice.

Solution 1

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.

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).

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.

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.

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.

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).

Solution 2

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

Yes they are both C++ compilers but:

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

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.

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

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.

Good luck.

Updated for 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

This still comes up on Google searches, so updated again for Berlin 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

Solution 3

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.

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.

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

Most of the serious complaints about C++Builder have been often centred on it's compliance with standards like the the STL and 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.

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

Solution 4

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.

Solution 5

C++ Builder PM here.

C++ Builder has some specific strengths:

• 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.

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.

View more solutions

Comments

[casablanca]

Try asking on programmers.stackexchange.com

[Seth]

I feel your pain. I am considering wrapping the legacy C++ code with C++/CLI and using C# and WPF for the front end to remove my dependencies on VCL and hence RAD Studio. However, I might post a new extension to your question to gauge community opinion.

[SQLMason]

about 7 years later... what did you do?

[Server Overflow]

Switch to Delphi. It was always more up to date than cppbuilder

[Stuart Golodetz]

Visual Studio Express (which includes the debugger) is free these days, and you're allowed to use it to develop commercial products. Eclipse is decent enough for Java, but there's no comparison between it and Visual Studio for C++ IMHO.

[Tommy Andersen]

I would not recommend upgrading to VS2010 at present time, most companies have a sound policy of not upgrading to new versions before the first service pack (some even before the first two). VS 2010 brings a lot of interesting additions, but it is at best still buggy.

[Afghan Host]

Thanks, some good comments. As I mentioned, (maybe not very clear) I'm at a cross road where we can afford to make a IDE switch and consume a learning curve. We don't use boost, STL, or anything outside straight up C++ constructs and, of course, VCL. Some VCL controls we found no equal in wxWidgets for the way we use them so that's another pain point we'll need to address.

[Afghan Host]

Tend to agree with most comments. Switching languages, though, is not an option. None of us know obj-Pascal nor do I care too. We have some low level driver stuff we've done that I fear replicating in Delphi would be a nightmare. And Delphi is owned by same company so not sure what that buys me.

[Afghan Host]

OK, but have you migrated a C++ Builder application to VS while at same time going to another RAD framework like wxWidgets or going to MFC?

[Afghan Host]

I should say cost, in terms of IDE, is not a road block. In other words, I can afford the upgrade cost of Builder XE or the cost to switch to VS but justifying it in terms of long term road map is really what I'm looking for. I've been playing with demo version of XE and while I see major improvements, I see some of the same old poor behaviors still exist!!! I'm grappling with should I spend time going to VS (or something) or figuring out another set of idiosyncrasies to deal with Builder XE's bugs.

[Tommy Andersen]

Drivers and graphical interface does not have to be written in the same language in most situations, in fact it often won't be. It is true that Delphi is a Embarcardero product, but this gives you the opportunity of keeping existing libraries. Besides you have the option to switch to Free Pascal. One more thing, the switch from C++ using the VCL to Delphi is not a big one. VCL is written in obj. pascal.

[Zach Saw]

We've moved from C++ Builder to C# with ease. Most of the VCL controls we've used in C++ Builder have their equivalent counterparts by the same vendors in .NET. I remember when I moved to C#, I found it to be the natural continuation of C++ Builder. Features (language, IDE, framework) that I've wanted for years in C++ Builder were finally available in C#!

[Afghan Host]

interesting, would be curious to hear about your success and issues faced including how you dealt with them. Since I made this post, we've made more progress in terms of using wxwidgets. I have wxwidgets running under VS and CBuilder. The WxWidgets GUI builder is not very good in terms of productivity measures. In CBuilder, I can double click a GUI element (TButton) and it takes me right to the code. Not the case in the WxWidgets world... A gripe I have with developer tools that don't seem well thought out.

[Afghan Host]

and I absolutely hate Eclipse. It's a java app and I attribute this fact to it's sluggish behavior. I need an IDE that has ZERO lag. I'm an extremely fast typist (as are my developers) and we all customize our IDE for fast file saves, compiles, etc... Eclipse is just not there for us. I looked at Code::Blocks a long time ago and it seemed very immature at the time. I might spend a few hours reexamining it but my current time investment in WxWidgets seems promising so far aside from the fact they don't have an as good GUI designer or integrated tool chain as the CBuilder one is.

[Gregor Brandt]

64 bit supported as of XE5

[M.M]

Adding to this; C++Builder 64bit now uses clang backend, so it's fixed points 3,4 moving forward. Unfortunately the 32-bit targets sill use the old, awful compiler.

[Gad D Lord]

How did that ended. Were you successful?

[Remy Lebeau]

Successful in what? The situation is as stated. Nothing was ever ported to .NET. Existing projects were kept in C++Builder and only a few are still being maintained, everything else was re-written from scratch in C#.

[David]

Don't forget wxWidgets isn't perfect either - C++Builder has native controls, for example, if a native user experience matters to you. This question is very old (2010) and since then there's FMX (cross-platform, also native controls), Clang-based compilers for many platforms including Win32 and Win64, etc etc. As far as RAD goes I don't think there's much to compete with it, certainly not on the VC++ side.

[Yami Odymel]

After a year, the Code completion, Documentation, Code insight is still not improved (in Tokyo 10.2.3). It's still a pain with the C++ Builder IDE now.

[Mosolov Sergey]

trial version C++ Builder 10.3.2, VCL project, code completion works only with "Classic compiler", "Classic" compiler supports only C++98.