Fehlerbehebung der bcc64x-Toolkette (Win64 Modern)
Nach oben zu C++Builder-Anwendungsentwicklung für 64-Bit-Windows (Modern)
Im Folgenden sind einige häufig auftretende potenzielle Probleme aufgeführt.
Unerwartete Zugriffsverletzungen in Anwendungen im Release-Modus
Neuere Versionen von Clang und LLVM handhaben undefiniertes Verhalten (UB) strenger. Eine häufige Klasse von undefiniertem Verhalten ist eine nicht initialisierte Variable, bei der der Wert der Variablen zufällig sein kann.
In der Vergangenheit konnte dies compiliert werden, und Ihr Programm schien zu funktionieren.
In neueren Versionen von Clang, wenn Optimierungen aktiviert sind (was bedeutet, dass LLVM strenger mit UB umgeht, weil es dadurch mehr Optimierungen vornehmen kann) und eine nicht initialisierte Variable verwendet wird, fügt LLVM eine Trap-Anweisung ein. Dies führt zur Laufzeit zu einem Absturz.
Um dies zu beheben, erzeugen Sie den Build mit -Wuninitialized und beheben Sie jede Warnung, indem Sie sicherstellen, dass jede Variable immer initialisiert ist.
-Wall zu erzeugen und alle Compiler-Warnungen zu beheben.Absturz, wobei der Speicher 0x80 Byte beträgt
Der UCRT-Speichermanager füllt freigegebenen Speicher mit Werten von 0x80.
Wenn ein Absturz auftritt und der Speicher, auf den zugegriffen wird, mit diesem Wert gefüllt ist (z. B. 0x80808080), bedeutet dies, dass der Speicher freigegeben wurde. Um dies zu beheben, müssen Sie die Ursache für den Zugriff auf diesen Speicherplatz/dieses Objekt/diesen Zeiger ermitteln, nachdem er/es freigegeben wurde.
Langsame Compilierung
bcc64x sollte ungefähr die gleiche Compiliergeschwindigkeit wie frühere Clang-Compiler zeigen. Ein häufiges Problem ist die Anzahl der Warnungen, die der Compiler ausgibt: je mehr Warnungen, desto langsamer wird er.
Da Warnungen oft ein korrekt auf mögliche Probleme hinweisen, ist es empfehlenswert, diese zuerst zu beheben.
Sie können auch bestimmte Warnungen deaktivieren, z. B. die foo-Warnung mit #pragma clang diagnostic ignored -Wfoo.
Wir empfehlen zudem, TwineCompile für die parallele Compilierung zu verwenden. Dies wird im GetIt-Package-Manager für Kunden mit aktiver Wartungsvereinbarung bereitgestellt.
Doppelte Symbole beim Erzeugen mit bcc64x in der Befehlszeile
Wenn Sie direkt mit bcc64x und ld.lld compilieren anstatt mit msbuild oder der IDE, werden möglicherweise Fehler zu doppelten Symbolen ausgegeben.
Doppelte Symbole werden in C++ standardmäßig als Fehler behandelt, aber beim Linken mit Delphi werden einige Duplikate erwartet, was lästig sein kann. Aus diesem Grund ignorieren die IDE und die msbuild-Compilierung diesen Fehler bereits standardmäßig.
Um doppelte Symbole zuzulassen, muss das Flag -Xlinker --allow-multiple-definition zur bcc64x-Befehlszeile hinzugefügt werden, um sie in Warnungen umzuwandeln.
Um doppelte Symbole zuzulassen, ohne Warnungen anzuzeigen, müssen die Flags -Xlinker --allow-multiple-definition -Xlinker --Wno-multiple-definition zur bcc64x-Befehlszeile hinzugefügt werden.
Ergebnisse der Compilierung werden nicht mit dem Quelltext-Editor synchronisiert
Die IDE bietet ein virtuelles Dateisystem, das es ermöglicht, neue oder geänderte Dateien mit dem Inhalt im Editor zu compilieren und nicht mit dem auf der Festplatte gespeicherten Inhalt. Unsere Integration der Clang 15-basierten Toolkette verwendet einen anderen Mechanismus als den, der in der IDE in der Vergangenheit verwendet wurde, um das VFS darzustellen (VFS-Overlay genannt, ein Clang-Feature). Dabei werden Dateien bei der Compilierung temporär auf der Festplatte unter einem anderen Dateinamen gespeichert und der Compiler und der Linker ordnen den gesuchten Dateinamen der temporären Datei zu.
Obwohl es keine bekannten Fehler gibt, können Sie die temporären Dateien aufbewahren, um den Inhalt der compilierten Anwendung zu überprüfen und eventuelle Unstimmigkeiten zwischen dem, was im Editor oder Formular-Designer (auch Text und eingebunden) angezeigt wird, und der compilierten Anwendung zu diagnostizieren.
Wählen Sie dazu Projektoptionen > Erzeugen > C++-Compiler > Erweitert aus und deaktivieren Sie Temporäre VFS-Dateien nach Compilierung entfernen.
Der Befehlszeile in der Compiler-Ausgabe im Meldungsfenster können Sie entnehmen, welche Dateien compiliert wurden und welche Dateinamen überprüft werden müssen.
Fehler: Verwendung vom nicht deklariertem Bezeichner ServiceController
Bei der Migration von altem Code des klassischen Compilers zur neuen Toolkette können neue Compilierfehler auftreten. Diese Fehler weisen häufig auf ungültigen Code hin, den der klassische Compiler zuvor fälschlicherweise akzeptiert hat. Ein solcher Fehler ist:
[bcc64x Fehler] %s(%d): Verwendung vom nicht deklariertem Bezeichner "ServiceController"
Dieser Fehler tritt typischerweise in Code auf, der automatisch vom Experten für neue Projekte in älteren Versionen der IDE generiert wurde, insbesondere für Service-Anwendungen oder DataSnap-Server.
Beispiel des Problems:
typedef void (*TServiceController)(unsigned);
class TTest
{
public:
TServiceController GetServiceController();
friend void ServiceController(unsigned CtrlCode);
};
TServiceController TTest::GetServiceController()
{
return ServiceController;
}
void ServiceController(unsigned CtrlCode)
{
}
In diesem Fall tritt der Fehler auf, weil der durch eine friend-Deklaration eingeführte Name weder für die qualifizierte noch für die unqualifizierte Namenssuche sichtbar ist, bis derselbe Name im nächstgelegenen umschließenden Bereich deklariert wird. Um dieses Problem zu beheben und den Code gültig zu machen, verschieben Sie den ServiceController- vor den GetServiceController-Member.