C++Builder: The Early Days

By David Millington, C++ Product Manager

C++Builder 1's icon, a dark blue outlines city with construction crane

C++Builder’s origin comes from Borland staff having observed the success of Delphi, with its UI libraries and elegant property-method-event model, together with the rise of C++. At the time C++ did not have great UI libraries – it was stuck with libraries like MFC, using older paradigms and without as powerful a visual designer, or Borland’s own OWL which, though solid technology, was becoming similarly dated in approach – and the engineers at what was then Borland realised that with only a few language extensions, C++ could use the same model as Delphi… and even interoperate seamlessly with Delphi code. First announced at COMDEX on 18th November 1996, C++Builder 1 was shipped on Feb 26, 1997.

Screenshot of C++Builder 1 on Windows 98, showing the form designer with a one-button app and behind it the code editor
C++Builder 1 on Windows 98, showing the form designer with a one-button app and behind it the code editor

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!

The C++Builder 1 team. From left to right: Jesper Schultz, Roland Fernandez, Eli Boling, Jeff Peters, David Wilhelm, Lee Cantey, Carolyn Wiegley, Bruneau Babet, Herbert Czymontek, Shea Anderson, Judy Fitzgerald, Keimpe Bronkhorst, Peter Sollich, John Kline.

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.

Compiler Technology

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.

C++Builder Today

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.

C++Builder 11, with the main window and a secondary window editing the same form/unit (as you might with two monitors)

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!

Random Facts

  1. Every product release inside then-Borland and now Embarcadero has a codename. C++Builder 1’s codenames were Pronto, Presto, and SciFi, reflecting the excitement and radical change the product offered in the C++ world. C++Builder 3’s codename was Ebony (Delphi 3, the equivalent Delphi generation, was Ivory.) C++Builder 4 was Thunder, version 5 Rampage, and version 6 Riptide. The first merge of Delphi and C++Builder into one IDE, BDS 2006, was known as DeXter. Today we use more gentle codenames, naming after mountains and rivers. Version 11 Alexandria has the codename Olympus, whereas the upcoming 11.1 is known as Zambezi.
     
  2. The toolchain has a long history of supporting non-Windows platforms: did you know that Borland shipped C++ compilers for Nokia and Symbian mobile devices? Today you can use C++Builder for Windows and iOS.
     
  3. There was no C++Builder 2! The successor to C++Builder 1 was C++Builder 3, skipping version 2 to align with the same version number each generation as Delphi.
     
  4. The property-method-event (PME) model of UI development was even proposed to the C++ standards committee in 2002 (N1384, PDF.) There were arguments about it, such as proposal N1615 in 2004 (PDF), which gave mixed reviews about how useful they were for development, but how they didn’t quite match with what felt C++-ish. These days perhaps the view would be different, with many of those objections able to be handled. Who knows – maybe someday what makes C++Builder special will be in core C++ itself!
     
  5. On Win64, C++Builder uses an object file format called ELF, and a debug info format called DWARF. These are usually used on Unix or Linux platforms, as the Tolkien flavour of the names hints. When you maintain the entire compiler toolchain stack you can use any object format you want, and in fact the main reason they were chosen for Windows goes back many years to existing code used by Kylix (Delphi for Linux from 2001), leveraged by the team working on Clang ten years later.
     
  6. XE3 Update 1’s 64-bit C++ compiler was the first time Clang was brought to Windows, by anyone!
     
  7. If you want to see who has contributed to C++Builder over the years, then in C++Builder or RAD Studio 11, open the About box, hold Alt, and type TEAM. But the product has been helped over the years by many more people too: again in the About box, hold Alt, and type KUDOS to see all those we owe thanks for their contributions.

 

History

Some of the key milestones in C++Builder’s chronology:

  • February 26, 1997: C++Builder 1! Bringing the power of Delphi’s VCL to C++ customers, it allowed easy Windows programming in C++ for the first time. Read the original Borland press release.
     
  • February 5, 2002: C++Builder 6. A “classic” release in its robustness and features, this is still renowned today
     
  • 23rd November 2005 – In the form of Borland Developer Studio 2006, C++Builder and Delphi are released together in a single grouped IDE.
     
  • August 25, 2008: C++Builder 2009  switched to full Unicode support throughout the UI libraries and RTL, with early adoption of the then-C++0x standard plus a ribbon control and integrated Boost library
     
  • August 31, 2011: C++Builder XE2 added support for building Mac OS X applications
     
  • December 10, 2012: Update 1 for C++Builder XE3 added support for building 64-bit Windows applications, followed up with the XE4 release in April 2013; this was the first time any vendor shipped Clang for Windows
     
  • 11th September, 2013: C++Builder XE5 added support for building iOS applications
     
  • April 15, 2014: C++Builder XE6 added support for building Android applications
     
  • November 21, 2018: C++Builder 10.3 Rio added C++17 support
     
  • September 10, 2021: C++Builder 11 Alexandria released
     
  • ??? 2022: C++Builder 11.1 released!

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.