By David Millington, C++ Product Manager
In 1997, something amazing happened in the C++ world. Only a few years after the STL was defined, and a year before what was soon to become the canonical version of C++ for over a decade in the form of C++98, engineers at the legendary compiler company Borland recognised a problem in the popular language. C++ was great for its purpose in terms of libraries and algorithms, but not good at rapid development and creating user interfaces.
Their solution? Leveraging their expertise with Delphi, which had transformed Windows development just two years before, they offered a version of C++ with minimal language extensions that could bind to UIs elegantly – plus could be used with libraries built in another language. Ultimately, this swift, clean productive code + UI connection in C++ is the productivity solution that C++Builder provides to you.
Read on for more of the tech, or if this solution sounds useful (hint: it is!) you can try out C++Builder today.
The problem of matching C++ paradigms, powerful as the language is, with user interfaces in a clean C++-ish way is still a problem for the majority of C++ products today.
User interfaces are fundamentally built on a paradigm of events (something happening such as clicking a button, dispatched to an arbitrary handler), and properties wrapping state with side effects (a window has a title; while you can get and set it via methods, properties provide field-syntax presentation of the state.) Neither of these match C++’s ordinary features, and even today only one of those two has even arguably been addressed in the language. Yet, applications with user interfaces that use these paradigms are very common, and C++ is very powerful. It’s a natural step to provide a solution.
If your business writes software with a user interface – and that’s the vast majority of software! – you need a solution that lets your engineers build and connect your C++ code to that UI easily.
C++ had no clean way to connect between events – something happening – and calling an arbitrary method belonging to a particular object instance. Then-normal C-style function pointers don’t handle it in an object-oriented way. Even today, with std::func and std::bind, this can be ugly especially if the methods you want to call have a common signature only, rather than a common ancestor type with a specific method.
But for UIs, you want that generic handling: you want to be able to say, ‘when this button is clicked, call a method with these parameters on this object instance. But there are no restrictions on common base classes, no interfaces, it’s not a virtual method, just something that fits the criteria of what data is passed to it’. It’s this requirement that lets you have event handlers: a series of methods that can be on any class that can be attached to events.
Other C++ toolchains handle this other ways: Qt is the most famous with its pre-build processing and moc. But a language should not need preprocessing. It should be powerful enough on its own. And that’s what the C++Builder engineers created. They added a small language extension: an object-oriented function pointer, which could be bound on a class’s method’s signature only, not on type, and would carry the object instance as part of its data.
This allowed easy delegation of event handling to any object instance: for example, a button’s click event could be delegated to the window the button belonged on, or even an intermediate class as you might for a view/model/data separation architecture. You can read more about this language extension, called __closure, on the C++Builder docwiki.
The second major language extension the C++Builder engineers made was to add properties. Properties wrap state, such as the text displayed in a window caption. The most useful two aspects of a property are lazy evaluation – you may not create a resource, such as a window handle, until it is read – and side effects when setting, such as ensuring setting the window caption makes the window caption repaint. Sure, you can get and set that state with Get and Set methods, and a setter can have side effects, but binding to multiple methods isn’t clean, nor does that allow for simple state that can be field access, often useful when reading the state.
C++Builder’s properties provide field-like semantics that can be backed by methods, and this leads to an intuitive programming model where state is read and written through the same identifiers with the right behaviour happening due to the property semantics. You can read more about properties on the C++Builder docwiki.
Language cleanliness matters. C++ isn’t suitable for the above clean semantics. Rather than changing a programming model to adapt to a language that can’t cleanly implement it, the engineers believed it was better to adapt the language to be flexible enough to fit an intuitive programming model. History has shown they were right to do so: this same property-method-event model is used widely across Qt, C# with its UI libraries, Microsoft’s C++ extensions in a less powerful form, and other UI frameworks across other platforms. The lesson is clear: the model is useful, and everyone keeps re-inventing it and trying to adapt C++ to fit. Yet today, C++Builder is still the only C++ environment with this inbuilt language adaptation, a clean and elegant approach, to this UI programming model.
In 2002, this model was suggested for adaption into the C++ standard (N1384, 2002 (PDF).) Similar models inspired by ours were discussed as part of C++/CLI in 2004 (N1600, 2004) and as potential inclusion in the C++ library (N1615, late 2004 (PDF)), which spoke in glowing terms of how easy it made writing software.
There are reasons why it might not be adopted into C++: it’s hard to get a reference to a property, for example, without making language changes that wrap a readable and writable object in the same way there is a callable object. That’s completely doable, and maybe one day we’ll see it in the standard. Today we still get regular questions if it will be included in the standard, often from people completely outside our toolchain. We’re glad that even if C++ hasn’t adopted it, you can still use the power of this model with C++Builder.
It’s not just adding small but powerful language extensions that make it easy to adopt productive programming models that makes C++Builder special. C++Builder pioneered language interoperation: with its sister product Delphi, you can use two languages to compile into the same binary, and that share the same binary interface (ABI.) You can even write a C++ class that inherits from a Delphi class. Today, we see this more commonly, with Java and Kotlin, or the various .Net languages. It’s still rare for C++, where most languages take the approach of bindings (translation or wrappers) more than the true inbuilt interoperability approach of ABI compatibility.
This opens up the third major advantage of C++Builder: taking advantage of more libraries, and especially the power of the core libraries it ships with. C++Builder developers can use Boost, or {fmt}, or any other powerful C++ library. They can also use the vast number of libraries built with its sister product Delphi, and this includes the core user interface libraries, the Windows native UI library known as the VCL, and the cross-platform framework FireMonkey. The VCL is especially notable: wrapping the Windows API in clean, object-oriented components, with visual form design, it’s a mix of clean APIs and power while still allowing under-the-hood access. Today Microsoft is building a new object-oriented UI framework with a C++ interface called WinUI, and it’s still not finished; C++Builder has provided the equivalent functionality for twenty-five years. And it’s better than what it wraps: the VCL’s high DPI support, for example, is objectively better in key ways than that of the Windows API it wraps and provides a library for.
The converse of providing something twenty-five years ago that’s continuously maintained and kept modern is that it has meant, for that entire period of time, someone using the product could rely on still being able to use it. How many other technologies have been deprecated in that time? In business terms, a bet on C++Builder was a bet that a business could rely on. That continuity, that an app built with the VCL in 1997 could be compiled in 2022 even when the VCL is significantly more advanced, provides a real sense of reliability. It’s a business choice of high power mixed with low risk. This is our way of doing business and we want you to be able to rely on C++Builder for the next twenty-five years, too.
Software that’s been around a long time stays around. It’s proved its worth and power. C++Builder pioneered many things, and implemented them well. Over time it’s migrated technologies, now using Clang for example, while retaining that key compatibility that’s provided robust upgrade reliability for years. We’ve done studies that show customers build their apps with C++Builder up to five times faster than with other C++ environments. Low risk, long-term reliability, innovative language extensions, a policy of moulding the language to fit the model, modern toolchains, and productivity: here’s to the next twenty-five years.
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.