Dépannage de la chaîne d'outils bcc64x (Win64 Moderne)
Remonter à Développement d'applications C++ Builder Windows 64 bits (Moderne)
Les problèmes les plus fréquents sont présentés ci-dessous.
Violations d’accès inattendues dans les applications en mode Release
Les derniers compilateurs Clang et LLVM sont plus stricts concernant les comportements non définis (UB). Les variables non initialisées comptent parmi les comportements non définis les plus fréquents (la valeur de la variable peut être aléatoire).
Auparavant, ce type de code était compilé, et le programme pouvait sembler fonctionner correctement.
Dans les versions plus récentes de Clang et lorsque les optimisations sont activées, (c'est dans ce cas que LLVM est plus strict vis-à-vis des comportements non définis, car il effectue davantage d'optimisations), LLVM insère une instruction d'interception lorsqu'une variable non initialisée est utilisée. Cela provoque un plantage à l'exécution.
Pour résoudre ce problème, construisez votre application avec -Wuninitialized et résolvez chaque avertissement en vous assurant que toutes les variables sont initialisées.
-Wall par défaut pour la compilation et de résoudre les avertissements du compilateur.Plantage lorsque la mémoire contient 0x80
Le gestionnaire de mémoire UCRT remplit la mémoire libérée avec des valeurs 0x80.
Si vous expérimentez un plantage et que la mémoire est remplie par cette valeur (par exemple, 0x80808080), cela signifie que cette mémoire a été libérée. Pour résoudre le problème, identifiez la cause de l'accès à ce pointeur/objet/emplacement mémoire après sa libération.
Temps de compilation lent
La vitesse de compilation de bcc64x est approximativement équivalente à celle des anciens compilateurs Clang. Le nombre d'avertissements émis par le compilateur est l'une des principales causes de ralentissement. Plus le nombre d'avertissements est élevé, plus le compilateur est lent.
Les avertissements doivent être corrigés, car ils signalent généralement des problèmes potentiels.
Vous pouvez aussi désactiver certains avertissements en utilisant #pragma clang diagnostic ignored "-Wfoo" pour désactiver l'avertissement “foo”.
Nous recommandons également d'utiliser TwineCompile pour la compilation parallèle, disponible dans le Gestionnaire de packages GetIt pour les clients disposant d'une maintenance active.
Symboles dupliqués lors de la compilation avec bcc64x en ligne de commande
Si vous compilez directement avec bcc64x et ld.lld au lieu d'utiliser msbuild ou l'EDI, vous risquez d'obtenir des erreurs de symboles dupliqués.
Les symboles dupliqués sont généralement traités par défaut comme des erreurs dans C++. Toutefois, dans Delphi, certains doublons sont attendus, ce qui peut être gênant. C'est pourquoi cette erreur est ignorée par défaut dans les compilations effectuées dans l'EDI et msbuild.
Résultats de compilation non synchronisés avec l’éditeur de code
L'EDI fournit un système de fichiers virtuel qui permet que les fichiers nouveaux ou modifiés soient compilés avec le contenu présent dans l'éditeur plutôt qu'à partir du contenu stocké sur disque. Notre intégration de la chaîne d'outils basée sur Clang 15 utilise un mécanisme différent de celui auparavant utilisé dans l'EDI pour représenter le système de fichiers virtuel (VFS, une fonctionnalité de clang), en stockant les fichiers temporairement sur disque avec un nom de fichier différent lors de la compilation. Le compilateur et le lieur mappent ensuite le nom de fichier au fichier temporaire.
Bien qu'il n'existe pas de bugs connus, vous pouvez conserver les fichiers temporaires pour vérifier le contenu en cours de compilation et diagnostiquer d'éventuelles incohérences entre le contenu présent dans l'éditeur ou le concepteur de fiche (y compris le texte et les liens) et l'application compilée.
Pour cela, accédez à Options de projet > Construction > Compilateur C++ > Avancées, et désactivez ‘Supprimer les fichiers VFS temporaires après la compilation’.
La ligne de commande de la sortie du compilateur affichée dans la vue Messages vous permet de voir quels fichiers sont compilés et quels sont les noms de fichiers à vérifier.
Erreur : utilisation de l'identificateur non déclaré ServiceController
Si vous migrez du code généré avec le compilateur classique vers la nouvelle chaîne d'outils, vous pouvez rencontrer des erreurs de compilation. Ces erreurs mettent en évidence le code non valide que le compilateur classique autorisait à tort. Le message suivant compte parmi ces erreurs :
[Erreur bcc64x] %s(%d) : utilisation d'un identificateur non déclaré 'ServiceController'
Cette erreur se produit généralement dans du code généré automatiquement par l'Expert pour les nouveaux projets créés avec d'anciennes versions de l'EDI, et concerne plus particulièrement les applications de service ou les serveurs DataSnap.
Exemple du problème :
typedef void (*TServiceController)(unsigned);
class TTest
{
public:
TServiceController GetServiceController();
friend void ServiceController(unsigned CtrlCode);
};
TServiceController TTest::GetServiceController()
{
return ServiceController;
}
void ServiceController(unsigned CtrlCode)
{
}
Dans ce cas, l'erreur se produit, car le nom introduit par une déclaration friend n'est pas visible pour la recherche de nom qualifié ou non qualifié tant que ce nom n'est pas déclaré dans la portée englobante la plus proche. Pour résoudre ce problème et corriger le code, déplacez ServiceController avant le membre GetServiceController.