By David Millington, C++ Product Manager
It was immediately wildly successful. While I don’t have access to 1997’s sales numbers, some back-of-the-envelope math based on the memories of someone from that time indicates it may have sold at or close to the low six figures in terms of numbers of copies in the first eighteen months: an immense sales number for the time. Don’t quote this in Wikipedia: it’s hand-wavy; but what we do know for sure is that C++Builder was immensely successful.
While today C++Builder and Delphi are shipped together in the one multi-language IDE, RAD Studio, that wasn’t always the case. Back when C++Builder began, and in fact until 2005 with the release of Borland Developer Studio 2006, Delphi shipped first and the equivalent C++Builder version shipped shortly after.
In 1997 the core C++Builder team reported to Jesper Schultz, though the Delphi team were always regarded as part of the C++Builder team: BDS2006 unified in the product what was always the case among the team. Key people you may have heard of worked on it – but a vast number of people who may be known to you only from the credit Easter Eggs are responsible too. There are many lesser-known but brilliant individuals who should have their names seen!
In 2002, C++Builder 6 was released, widely known as a classic release in terms of features, usability, and popularity. In fact, C++Builder 6 was the first version of C++Builder I used. The C++Builder compiler was ‘the’ compiler to use in the industry, even as GCC and others were working to catch up.
But then came something different. One part of C++Builder history you may not have heard of is C++Builder X, released in September 2003. This was a big change in direction for C++: making use of the JBuilder IDE, C++Builder X ran on Windows, Linux and Solaris, and supported the same Borland C++ compiler but also Intel’s, Microsoft’s, or any other. The aim was to be a generic C++ IDE, but the product was not a success. Customers wanted what made C++Builder special: the ‘magic’ of the Windows VCL UI library and the language extensions that made creating apps fast, plus the ability to migrate their apps forward. While still spoken of fondly by many who worked on it as an exciting product and a strong move to standards-based C++ rather than custom extensions, based on customer response it was a misstep, and two years later Borland released C++Builder 2006, returning to the classic codebase.
Returning to the history of C++Builder as it originally was and as we know it today, its compiler, known today as the ‘classic’ compiler, was famous for being faster than other compilers in the industry. One reason it was fast was its architecture: today, it’s normal for compilers to parse an entire translation unit of source code, build an AST (an abstract syntax tree, basically an in-memory representation of what the source represents), generate an intermediate representation (IR) likely performing many transformations on that, and give that to a backend that itself may do some transformations. This is a three-phase (frontend, intermediate representation, backend) and multi-pass model, the model Clang and LLVM implements.
But the classic compiler was different: it would read a block of source at a time – a method, or maybe even just an if-block or for-loop – generate enough of an AST for just that block, and hand that over to the backend which wrote to the object file: effectively a two-phase (frontend, backend) single-pass (hand-waving at the optimisations the backend performed here) model, using a backend originally shared with but now separate to Delphi’s. This was immensely fast, but limited the understanding of the compiler of the entire source, including for compiler optimisations.
That classic compiler grew out of Turbo C and Turbo C++, and was one of the first to implement templates: in fact, in the 2000s, there were two template models: Cfront and Borland. Over time more language features were added to the classic compiler, including some from what would become C++11, and the compiler is still shipped today for those who want to use it, even if it’s not the default. Yet eventually C++Builder switched to using Clang. Why? There were many reasons: an ageing codebase coming from Turbo C and written mostly in C; an older architecture hard to adapt to modern needs as noted above; but fundamentally the item that really caused Embarcadero to switch was templates.
C++11, the second major version of C++ (C++98 being the first) added more powerful template technology, especially variadic templates. The compiler architecture was showing its age, and was going to be very hard to rework to add these and some other key C++11 features. In 2011 Clang and LLVM were rapidly-moving projects, and it was clear that they provided a well-architected path forward to which it would be easier to add custom behaviour. While macOS (then OS X) support was added to C++Builder in 2011 using the classic compiler, in parallel an internal effort was under way to add C++Builder’s language extensions to Clang.
XE2, the same version that shipped OS X support with the classic compiler, shipped C++ Audits (a now-removed feature.) The audits feature was based on Clang 3.1, and using it for audits in one version let the team test their customised Clang on real-world source code using C++Builder’s syntax and extensions before shipping a compiler that supported those extensions. The compiler shipped in Update 1 to XE3, and the Embarcadero team led Clang history here as the first to bring Clang to Windows, followed later by Google and Microsoft.
Clang 3.1 was rapidly updated to Clang 3.3, and then later to Clang 5 in 2018 when C++Builder added C++17 support.
Since then, focus has been on compatibility and support, ensuring quirks in various common C++ libraries are supported, or adding RTL methods that are relied on although not always standard. This means that C++Builder today not only has modern C++ support, but does an excellent job at compatibility with source code written with other compilers in mind.
As well as any open source or third party C++ library, C++Builder today supports the excellent native Windows UI library, the VCL, with its high DPI support, as well as FireMonkey, the cross-platform UI framework, and delivers its trademark rapid development productivity. This mix of C++Builder’s ‘magic’ plus excellent compatibility mean it’s a great tool to make use of open source C++ libraries while building applications fast, and we see its use increasing in the industry steadily today. We look forward to another 25 years!
Some of the key milestones in C++Builder’s chronology:
C++Builder celebrates 25 years on Feb 26, 2022!
Embarcadero have created a fantastic poster showing C++Builder’s history in a timeline with other key development events. This is perfect for printing out and placing on a wall near your desk, or even just opening as a PDF and browsing. It’s massive and detailed.
Industries from engineering to scientific research, textiles to green electricity, museums to department stores, everyday useful apps that you might not even know are made with C++Builder up to industrial grade software deployed across entire countries and used by millions: you’ve used software made by C++Builder, and those developers got their job done fast, and done well, due to its productivity and libraries.
It began 25 years ago. It’s only grown. And you can use it today.