Vor ein paar Wochen haben wir RAD Studio und C++Builder 11.3 veröffentlicht, ein Qualitäts-Release, das von vielen als die beste aller aktuellen Versionen gelobt wurde. Diese Version baut auf mehreren 11.x-Versionen auf, einschließlich unserer speziellen C++-Qualitätsversion 11.1.5. Vor dem Hintergrund dieser Qualität möchten wir Ihnen unsere Pläne für die Zukunft vom C++Builder und C++ in RAD Studio vorstellen.

Wir sehen Fragen zu unseren Plänen für C++Builder in mehreren Bereichen: Unterstützung für neuere C++-Standards wie C++20 und C++23, Verbesserung des Debuggers, Lösung von Problemen beim Linken großer Projekte, STL-Qualität, Produktivität wie Code-Vervollständigung, Navigation und Refactoring sowie Unterstützung für andere Plattformen wie Android oder Linux.

Wir gehen diese Aufgabe in zwei großen Schritten an:

1. Aktualisierung von Clang – aber nicht einfach nur eine „Aktualisierung“ von Clang, sondern wir verfolgen einen ganz anderen Ansatz, den wir als „es richtig machen“ bezeichnen
2. Integration von Schlüsselfunktionen von Visual Assist in C++Builder

Sowohl das, was wir tun, als auch die Herangehensweise an das, was wir tun, ist sehr vielversprechend. Lesen Sie weiter – nicht nur um zu erfahren, was wir tun oder warum, sondern auch um Screenshots zu sehen, die die Entwicklung zeigen!

Upgrade auf Clang 15

Die Compiler von C++Builder basieren auf Clang, erweitert um unsere Spracherweiterungen. Die Spracherweiterungen dienen der Interoperabilität mit Delphi: Falls Sie es noch nicht wussten, die beiden Sprachen können in dieselbe Anwendung kompiliert werden und sogar Klassen in C++ von in Delphi definierten Klassen erben lassen. C++ kann auch Delphi-implementierten Code durch übersetzte Header verwenden und darauf verweisen sowie Delphi-eigene Merkmale wie Eigenschaften verwenden.

Im Jahr 2018 haben wir ein Upgrade auf Clang Version 5 durchgeführt, das C++17-Unterstützung bot.

Jetzt aktualisieren wir unser aktuelles Clang, Clang Version 5, auf Clang 15 – ein gewaltiger Sprung bei den Funktionen und der C++-Kompatibilität.

Aber dies ist in vielerlei Hinsicht kein Upgrade wie unser vorheriges Upgrade (von 3.3 auf 5 im Jahr 2018).

In der Vergangenheit hatten wir immer unsere eigene Art, Dinge zu tun. Zum Beispiel verwenden wir ELF64 (typischerweise ein Unix/Linux-Objektdateiformat) als Objektdateiformat unter Win64 und DWARF als Debug-Informationsformat, aus verschiedenen Gründen.

C++Builder hat seine Hauptunterschiede, die unsere Vorteile sind: Delphi-Kompatibilität; die Spracherweiterungen; die Dinge, die es uns ermöglichen, Formulare und Frames zu entwickeln und die VCL und FireMonkey zu verwenden. Diese Unterschiede sind wertvoll. Aber unsere derzeitige Clang-Implementierung enthält einige benutzerdefinierte Elemente ohne besonderen Wert und verursachen allmählich Wartungskosten, ohne zu den insgesamt erstaunlichen Vorteilen von C++Builder beizutragen. Wir weichen aus Gründen der Legacy von den Plattformkonventionen ab. Würden wir uns jedoch an die Plattformkonventionen halten, würde das für uns weniger Anpassungen in unserer Toolchain bedeuten, weniger benutzerdefinierte Tools und für Sie eine deutlich höhere Kompatibilität bedeuten.

Daher ist das Clang-Upgrade nicht als ein Upgrade unseres bestehenden Compilers mit allem zusätzlichen Material geplant, sondern als ein Upgrade der Kernarchitektur unseres Compilers. Das bedeutet, dass wir planen, einen plattformspezifischeren Ansatz zu verfolgen: COFF-Objektdateien (das „native“ oder herkömmliche Windows-Format) auszugeben; das PDB-Format für die Fehlersuche zu verwenden; den LLVM-Linker und nicht ilink zu verwenden; und das bedeutet nicht nur, dass wir uns auf die Unterschiede konzentrieren können, die für uns wirklich wichtig sind, sondern auch, dass wir Open-Source-Tools und -Projekte wie den LLVM-Linker verwenden können. Mit anderen Worten, wir modifizieren Clang, um unsere Vorteile hinzuzufügen, nicht um Legacy-Technologie in modernes Clang zu übertragen.

Die Vorteile für Sie sind enorm: Kompatibilität mit vielen weiteren Tools, einfachere Verwendung (z. B.) anderer Debugger oder Analyse von Core-Dumps, neue Technologie zur Verbesserung der Effektivität unseres Linkers und vieles mehr. Sie erhalten die hochwertigen Sprach- und Integrationstechnologien – die Dinge, die C++Builder zu C++Builder machen – und das Gesamtprodukt ist viel robuster, kompatibler und moderner.

Runtimes und STL

Die Runtime einer C++-Toolchain besteht aus drei Schichten:

1. C-Runtime – sie bietet die grundlegenden Methoden der C-Sprache, Datei-IO im C-Stil usw.
2. C++ Runtime – stellt die Kernfunktionen von C++ zur Verfügung, z. B. die Ausnahmebehandlung
3. STL – verwendet die beiden oben genannten Schichten

In der Vergangenheit hatten wir unsere eigene C- und C++-Runtime. Wir bieten auch mehr als die Standardmethoden für eine Windows C-Runtime, einschließlich einiger POSIX-Methoden. Heutzutage ist eine C-Runtime jedoch eine in das Betriebssystem integrierte Windows-Standardkomponente, so dass wir die Verwendung der UCRT – Universal C Runtime – und das Hinzufügen unserer benutzerdefinierten oder erweiterten Methoden auf ihr evaluieren.

Unsere C++-Runtime wird höchstwahrscheinlich die gleiche bleiben, obwohl wir in einigen Bereichen einige Optionen untersuchen.

Die Arbeit am Clang-Upgrade ist bereits seit einiger Zeit im Gange. Einige Bereiche sind noch im Fluss, so auch die STL, die wir verwenden werden.

Release Pläne

Das Upgrade ist zunächst für Windows 64-Bit geplant. Damit wollen wir die Plattform anvisieren, auf die viele Entwickler umsteigen (64-Bit), und uns auf eine Windows-Plattform beschränken (so können wir uns auf eine Sache konzentrieren, die wir gut können). Wir planen, die gleiche Technologie und den gleichen Ansatz in einer zukünftigen Version auf Windows 32-Bit zu übertragen.

Was ist mit anderen Plattformen? Die Umstellung auf andere Plattformen mit einer älteren Version von Clang, Version 5, war keine ideale Situation. Die Umstellung auf eine moderne, aktuelle Version von Clang ist jedoch viel vorteilhafter und sobald wir das Upgrade für Windows abgeschlossen haben, werden wir in der Lage sein, den neuen Compiler auf andere Plattformen zu übertragen.

Ständig auf dem neuesten Stand

Neben dem Rollout auf Windows 32-Bit und andere Plattformen in den nächsten Releases planen wir auch, Clang auf dem neuesten Stand zu halten. Wir beabsichtigen, kontinuierlich auf dem neuesten Entwicklungsstand zu bleiben und eine neue Version von Clang sogar mit jedem Point-Release zu veröffentlichen.

Clang und LLVM entwickeln sich schnell, und nach der Veröffentlichung dieses Upgrades planen wir Änderungen aus den Remote-Repositories kontinuierlich in unsere zu integrieren. Im Gegensatz zu Delphi versucht C++Builder nicht, die ABI-Kompatibilität über Point-Releases hinweg beizubehalten, d. h. wir verlangen, dass Sie C++-Objektdateien und -Binärdateien, die Sie in jedem Point-Release verlinken, neu erstellen (beachten Sie, dass von Delphi generierte Objektdateien und Bibliotheken im C++-Stil stabil sind, es ist nur alles, was von einem C++-Compiler erstellt wird). Das gibt uns die Freiheit, schnell zu handeln, und in diesem Fall bedeutet schnell handeln, auf dem neuesten Stand zu bleiben.

Wir haben vor, mit jedem Release eine neue Version von Clang zu veröffentlichen.

Sie werden immer die aktuellste Version des Compilers und der Toolchain verwenden.

Clang Upgrade im Überblick

Wir aktualisieren Clang auf Version 15. Anstatt Legacy-Technologie nach vorne zu bringen, verwenden wir Plattform-Standard-Formate wie COFF und PDB; das schließt MS-ähnliche Mangling, nicht Itanium ein. Wir setzen ganz auf „Was unter Windows normal ist, ist auch für C++Builder normal“. Dadurch können wir Tools wie den LLVM-Linker verwenden und ilink vollständig ersetzen. Dadurch können Sie auch andere Tools wie Profiler verwenden, die so geschrieben sind, dass sie Formate wie PDB verstehen. Wir überarbeiten auch unsere Laufzeiten und verwenden eine neue STL, die viel zuverlässiger ist. Die ungefähre Sprachunterstützung wird C++20 und ein Großteil von C++23 sein. Wir veröffentlichen zuerst für Win64, Win32 und andere werden folgen. Kompatibilität mit unseren früheren RTLs und Toolchains ist der Schlüssel. Und schließlich führen wir kontinuierlich Upgrades durch, so dass Sie mit jeder Version und jedem Upgrade von C++Builder eine moderne und qualitativ hochwertige Toolchain (Compiler, STL und mehr) verwenden können, die sich auf dem neuesten Stand befindet.

Dies ist ein äußerst spannender Schritt für C++Builder, eine solide Grundlage und ein solider Ansatz. Intern wird dies als „es richtig machen“ bezeichnet, und das ist auch der Fall: Wir machen C++Builder richtig. Wir hoffen, Sie sind von diesen Plänen und dem Ansatz genauso begeistert wie wir!

Vorschau

Diese Arbeit ist noch nicht abgeschlossen, aber hier sind einige Bildschirmfotos als Vorschau. Wir haben daran gearbeitet, die C++Builder-Spracherweiterungen hinzuzufügen: Eigenschaften, Declspecs, Klassen im Delphi-Stil und Vererbung, Closures und so weiter.

Doch wir sind noch nicht so weit: Wir haben ein internes Stadium, das wir als „One-Button-App“ bezeichnen, in dem Sie eine VCL-Anwendung mit einer Schaltfläche erstellen und ausführen können, auf die Sie klicken können: Zu diesem Zeitpunkt funktionieren alle Schlüsselelemente. Diese Screenshots zeigen Befehlszeilenanwendungen. Es handelt sich jedoch um Anwendungen, die unsere C++Builder-Erweiterungen verwenden, mit COFF und PDB erstellt wurden und mit der Delphi-Laufzeit verknüpft sind. Im Laufe der Zeit werden wir mehr davon veröffentlichen und schließlich zu einem Punkt kommen, an dem wir nach Beta-Testern und nach Feedback suchen!

Hier ist ein Property-Test, der mit dem in Arbeit befindlichen Clang-Upgrade kompiliert wurde:

Beachten Sie, dass es eine PDB-Datei erzeugt.

Hier ist ein weiterer Screenshot, dieses Mal vom Debugging in der IDE:

Hier sehen Sie einige wichtige C++Builder-Mechanismen, die getestet werden: __classid (gibt die Metaklasse zurück), veröffentlichte Eigenschaften und Klassen im Delphi-Stil.

Unten in der Ereignisansicht sehen Sie die Version von LLDB, die wir verwenden, Version 15. Und darüber sehen Sie einen internen Build unserer IDE, die diesen C++-Code debuggt, kompiliert mit einem modernen Clang, mit moderner LLDB, im Quellcode mit unseren Erweiterungen, mit Debug-Informationen, die aus dem PDB-Format geladen werden.

Integration von Visual Assist

Das Clang-Upgrade an sich wäre schon eine tolle Neuigkeit für C++Builder, aber es gibt noch mehr.

Vor einigen Jahren erwarb Idera Visual Assist, ein sehr bekanntes Produktivitätswerkzeug für C++- und C#-Entwickler. Es bietet Codevervollständigungen, Refactorings, Navigation und viele weitere Funktionen und wird als Lückenfüller für Visual Studio angepriesen: Man kann mit Fug und Recht behaupten, dass Visual Assist ein besseres C++-Erlebnis bietet als Visual C++. Es wäre daher naheliegend, dass wir es verwenden, um die Lücken in C++Builder zu schließen.

Visual Assist ist ein umfangreiches Produkt, aber es gibt einige Schlüsselbereiche, die wir gerne in C++Builder einbringen würden: Unterstützung bei der Code-Vervollständigung, Hinzufügen von Refactorings und Bereitstellung von Navigationsmöglichkeiten für Ihren Code, z. B. beim Auffinden von Referenzen. Hierfür gibt es mehrere Schritte: Visual Assist unterstützt die Spracherweiterungen von C++Builder (bei den Builds, die an Visual Studio-Kunden ausgeliefert werden, ist diese Funktion nicht aktiviert), und wir arbeiten jetzt daran, wichtige VA-Funktionen zu integrieren. Wir arbeiten derzeit an der Integration in die RAD Studio IDE selbst.

Wir planen ein Rollout, bei dem Sie die wichtigsten Funktionen zuerst erhalten. Die erste Version wird wahrscheinlich nur ein oder zwei Refactorings und Navigation enthalten – und natürlich die Code-Vervollständigung. In jeder nachfolgenden Version werden wir mehr integrieren.

Vorschau

Visual Assist in C++Builder! Animiertes GIF im Vollbild anschauen

In dieser Bildschirmaufnahme sehen Sie, wie unsere interne IDE mit unserer ersten Visual Assist-Funktion, Find Symbol, gebaut wird. Damit können Sie Ihre Codebasis durchsuchen, einschließlich Code wie VCL-Header außerhalb Ihres Codes, und schnell zur Position eines Symbols navigieren. Dies ist eine gute erste Funktion, denn sie ermöglicht es uns, unsere Unterstützung für C++-Erweiterungen wie Eigenschaften zu testen (das sind Symbole, die in diesem Dialog angezeigt werden sollten).

Beachten Sie, dass bei der Eingabe von „grid row“ auch die FMX-Header durchsucht werden und von 172 Übereinstimmungen wird TCustomGrid.Row als die wahrscheinlichste ausgewählt. Wenn nur in der aktuellen Projektgruppe gesucht wird, wird Grid.Rows ausgewählt. Die Suche durch alle 226.236 FireMonkey- und lokalen Projektsymbole zusammen dauert nur 0,7 Sekunden, um das erste Ergebnis zu finden.

Modern Clang, COFF und Visual Assist?!

Clang upgraden.

Ein neues, aktuelles Clang für jedes einzelne Release.

Ein völlig neuer Linker.

Eine neue STL.

COFF und PDB und die damit verbundene Interoperabilität.

Neue Code-Vervollständigung.

Visual Assist C++ Navigation und Refactoring.

Man kann gar nicht hoch genug einschätzen, wie gespannt wir sind und wie sehr wir uns darauf freuen, Ihnen dies zur Verfügung zu stellen. Es sind aufregende Zeiten für einen C++Builder-Entwickler!

Haftungsausschluss: Alle neuen Funktionen und Verbesserungen, die in diesem Blog-Beitrag für zukünftige Versionen von RAD Studio diskutiert werden, sind bis zur Fertigstellung und Freigabe nicht verbindlich.

---

Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

---