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.
This means that the release of Visual Studio 2010 creates a new question: Does it make sense to upgrade Visual Studio even if you're not upgrading to .NET 4? The answer is "yes," and for a lot of reasons. But if you're going to .NET 4 you'll find a lot of support in Visual Studio 2010.
As soon as you start Visual Studio 2010 you'll notice that the Start Page is now more useful than the File menu (see Figure 1). The Start Page still provides access to project templates, but the rest of the page now provides organized access to training resources for the major .NET technologies.
Once you open a file you'll find that, thanks to Windows Presentation Foundation (WPF), there's more visual feedback in the editing window. For instance, if you click on a variable name, all uses of that variable name are highlighted. This feature isn't limited to variables -- clicking on a method header automatically highlights all the return clauses and the end of the method. But this extra highlighting isn't without a downside. When debugging, for instance, I sometimes lost the current line because its highlighting was overridden by the highlighting added for the currently selected item. aztec tattoos
Visual Studio is not really comparable to C++ Builder.
Yes they are both C++ compilers but:
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):
This still comes up on Google searches, so updated again for Berlin 10.1:
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.
I've worked in C++ builder 2006, 2009, XE6 and 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...).
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 :)
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.
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 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.