The future of C++ Builder

Question

A few years ago C++ Builder from Borland with its excellent VCL gui library and its gui designer was the best IDE for C++ development on Windows.
Once beloved, for a couple of years now Builder has been losing users steadily.
What do you think are the biggest mistakes Borland/Inprise/CodeGear/Embarcadero has made?

Answer 1

C++Builder gives you the worst of both the Delphi and the C++ worlds.

It was never as popular as Delphi, so you don't get the network effects that Delphi users get: example code is usually in Delphi and has to be translated to C++Builder, 3rd party components that support Delphi may not support C++Builder, 3rd party components are almost invariably written in Delphi so you almost have to purchase the full (and expensive!) RAD Studio (with Delphi) instead of just C++Builder to use them, C++Builder forums are empty compared to Delphi forums, and so on.

But it also has many disadvantages compared to straight C++. C++Builder's compiler's is buggy, and its standards support lags behind Visual C++ and gcc, so you can't use advanced C++ techniques or advanced C++ libraries (like Boost) without a lot of trouble. The IDE is not as fast, reliable, and featureful as more widely used IDEs like Visual Studio C++. The dependencies on Delphi introduce incompatibilities with C++ like constructor order and the requirement that VCL objects be constructed on the heap. The lack of a cross-platform version of the VCL undercuts C++'s portability advantage.

C++Builder 2009 improves the compiler (although many issues remain), and from what I understand, Embarcadero is actively addressing various other quality issues and is working on a cross-platform strategy, so this may change in the future. However, it's hard for me to see how C++Builder can start attracting new users. Qt offers native cross-platform C++ development, and the .NET Framework is Microsoft's preferred approach to Windows development, and both of these options seem better positioned for the future than C++Builder.

Answer 2

Borland didn't really make a mistake, they just didn't have deep enough pockets to keep Microsoft from buying out their Chief Architect.

See this story for a little background

Answer 3

I think most C++ developers are not very comfortable with the fact that they have to rely on framework written in pascal. Borland try to address this with C++ BuilderX several years ago. Have no idea where it is now.

Qt is now LGPL, Eclipse CDT is mature and Embarcadero is highly familiar with Eclipse. I highly anticipate some exciting news coming within few years.

Answer 4

"C++Builder gives you the worst of both the Delphi and the C++ worlds."

On the contrary. C++Builder allows you to write your project in both Delphi and C++. Delphi shows its strengths when its language additions come into play (such as the COM extensions, anonymous methods or RTTI), and C++Builder provides easy access to 3rd-party C++ libraries or Windows header files. For me, it's a productive combination.

"3rd party components that support Delphi may not support C++Builder"

Most of them work with C++Builder anyway. Granted, several incompatibilities in the C++ compiler made this a hard task sometimes (no proper class method support, no class reference type hierarchy, limited support for Delphi-style arrays), but almost all of them were fixed in C++Builder 2009.

"3rd party components are almost invariably written in Delphi so you almost have to purchase the full (and expensive!) RAD Studio (with Delphi) instead of just C++Builder to use them"

Not true. Even standalone C++Builder can compile Delphi code without problems.

"C++Builder's compiler's is buggy, and its standards support lags behind Visual C++ and gcc, so you can't use advanced C++ techniques or advanced C++ libraries (like Boost) without a lot of trouble."

This is true in some ways. At least, it's getting better by now. C++Builder 2009 supports Boost fairly well (and btw, it even comes with a pre-built Boost distribution).

"The lack of a cross-platform version of the VCL undercuts C++'s portability advantage."

I disagree. Cross-platform GUI has its own pitfalls; it's not always the right solution. C++Builder still allows you to write your GUI frontend with VCL and your numbercrunching backend in C++.

Answer 5

What do you think are the biggest mistakes Borland/Inprise/CodeGear/Embarcadero has made?

That sentence just about says it all. Regardless of the (low, IMHO) quality of their product, their biggest problem is that nobody has any faith that Borland (etc.) will continue to exist more than a week after buying their IDE. No customer confidence equals no customers.

That said, they do continue to exist, and have for many years now--I don't know how they keep doing it!

Answer 6

I'm using Borland/Codegear C++ Builder (2007) at work, and have done so for some time, actually since version 4. When criticizing C++ Builder for the terrible compiler, the missing code features in the IDE, etc. One has to keep in mind, the target area, of the C++ Builder. C++ Builder is just like Delphi (and the other Borland/Codegear IDEs) developed for Rapid Application Development (RAD).

For this reason the development focus has often been on providing a tool that allows the developer, to develop full scaled programs, whether it is database, network, or other visual programs - fast. It is so to speak centralized around the idea of developing applications fast, and not necessarily developing fast applications.

This idea was brilliant when Delphi was first introduced, and Delphi continues to be a nice program to develop in. However recent additions of Java and lately the .NET platform, has given the Delphi IDE some good competition in the RAD community.

While I definitely think that Delphi has earned its place, as a development IDE with several important programs being developed in it (ie. Skype); I find it more difficult to justify the existence of the C++ Builder. I see a lot of advantages in having an easy transition from Delphi to C++ and back, when using the VCL for instance. And C++ as a language do have some important aspects, especially considering the large amount of knowledge that exist on the internet on C++.

C++ Builder was at the time of it's release the easiest environment to build GUI applications for windows in, for C++. However recent frameworks like Qt and wxWidgets (although I haven't tried wxWidgets myself). Seem to do an equally good job, if not better, besides being native C++ - unlike the VCL.

One of the biggest problems of C++ Builder is the compiler, besides having had problems with the standard compliance, it is also extremely poor performer when it comes to optimization. For instance go to the options window, in here it is by default set to optimize for the 386 CPU, honestly, who develops windows GUI applications for the 386 processor nowadays. The newest CPU it can optimize for is the Pentium Pro processor, and like 386, who develops GUI applications for this? This is especially ironic considering that Codegear has made a lot of effort in making the version 2007 of Delphi and C++ Builder Vista ready.

As it has been said before in the comments and answers, when buying C++ Builder you live with the risk of it being discontinued. This is not good for sales, especially for larger companies, who could instead go for the Qt library with the Microsoft Visual C++. And at the same time, get a better compiler, with the possibility for the ultimate compiler (The Intel C++ Compiler).

Developing in C++ Builder, pretty binds you to use either Delphi or C++ Builder, since the VCL is Codegear only. This is especially troublesome when considering that Codegears enthusiasm with the C++ Builder, might have seen better days.

So what do I think Codegear should do, both to enhance the quality of C++ Builder, but also to increase the market trust in the IDE, and increase sales.

1. The compiler is in my oppinion the biggest bottleneck, the outdated optimizations, and lack of standard support, is annoying. It needs a thorough rework.

2. The VCL needs to be opened up, the major problem about this, is that VCL is written in Pascal and includes many language extensions to C++ due to the requirement of compatibility. This is a difficult task to solve. But by having alternative development solutions for the VCL the safety of choosing C++ Builder would be increased. It's easier to choose a product where you know that you have alternate options in case of C++ Builder being discontinued.

3. The force of C++ Builder is without doubt its use for fast development of GUI applications, but that should not be an excuse for not having simple code view features. The IDE needs a thorough modernization.

4. Finally I think that the stability of the program has been decreasing with each version they have released. I am tired of seeing exception windows when waiting for the Code Insight box to appear.

5. I'm still waiting for 64 bit support. :)

Well I know some of these points have been partly addressed by the 2009 release, but since I haven't tried it myself, I can't really confirm it or not. Anyway that was my thoughts on the C++ Builder, I must admit I have difficulty seeing the C++ Builder survive with the current competition. One might just as well use Delphi for things that one uses C++ Builder for.

Answer 7

I just have to have my saying here, even though the thread is long dead (much like builder itself) I would say that the the problem with C++ Builder and the reason that it continue to exist are the same. By offering their libraries like vcl, their own infrastructure like bpl's and own formats for almost everything they manage to lock in some customers (like me) which have the choice between sticking to the IDE's components, or face a massive rewrite.

Answer 8

For me the biggest drawback is the bad compatibility to other compiler linker formats.

We had to switch the platform, since we are not able to use DLLs from other compilers. As I know, C++ Builder still only supports its own OMF linker format. No support for COFF! A converter that only support C format does not count, since different compilers have different name mangling.

It would be a REALLY nice feature if I could use third party precompiled DLLs (binary) + header files out of the box!

Todays software does not live on its own, but is integrated in an Ecosystem.

Further more I'm looking forward to a new cross platform intermediate output format as it was realized in the LLVM.