Libération de qualité
C ++ Builder 10.4.2 apporte quelques fonctionnalités intéressantes qui, selon nous, vous aideront vraiment – la plus importante étant « Split DWARF », un moyen de réduire l’utilisation de la mémoire dans l’éditeur de liens en supprimant les informations de débogage. Si vous avez des projets qui repoussent les limites de l’éditeur de liens, vérifiez-le: cela peut résoudre vos problèmes (voir ce billet de blog .) Cependant, RAD Studio 10.4.2 dans son ensemble était aussi une «version de qualité». En fait, bien que 10.4.1 soit la version destinée à la qualité et 10.4.2 aux fonctionnalités dont vous avez besoin, nous avons résolu plus de problèmes dans 10.4.2 que dans 10.4.1!
Et C ++ Builder ne fait pas exception.
Gestion des exceptions C ++
Ce merveilleux jeu de mots présente le travail de gestion des exceptions que nous avons effectué dans 10.4.2. Si c’est trop long, voici le TLDR: 10.4.2 donne à vos applications une très grande stabilité et un comportement plus correct lors de la gestion des exceptions.
Nous analysons les catégories de rapports de problèmes que nous recevons et effectuons également beaucoup de travail qui nous aide à trouver des problèmes en interne. Une partie de ce travail consiste à prendre en charge les bibliothèques C ++ : l’utilisation de code externe est un bon moyen de garantir la compatibilité de notre chaîne d’outils. En raison de ces analyses, dans la version 10.4.2, nous avons révisé une grande partie de notre gestion des exceptions pour Windows.
Les scénarios que nous avons examinés sont les suivants:
- Exceptions dans le module , lorsqu’une exception est levée et interceptée dans le même binaire, par exemple dans un même fichier EXE.
- Exceptions inter-modules , lorsqu’une exception franchit une limite de module, comme être lancée dans une DLL mais interceptée dans un EXE. C’est une situation plus difficile à gérer, et les directives de codage indiquent qu’aucune exception ne doit s’échapper d’un module vers un autre… mais, nous voyons du code là où cela se produit et c’est un scénario important à aborder. Cela est courant avec les packages ou lorsque plusieurs DLL et un EXE sont regroupés en tant qu’application.
- Exceptions multilingues , lorsqu’une exception traverse des cadres de pile appartenant à la fois à Delphi et C ++. Les exceptions peuvent être levées dans une langue et interceptées dans une autre, ou franchir la frontière plusieurs fois.
- Lorsque tous les modules (par exemple un EXE et une DLL) sont liés statiquement , ou que tous les modules sont liés dynamiquement (RTL dynamique.)
- Exceptions OS, C ++ et SEH
- Les deux Win32 et Win64 plates – formes.
Beaucoup de ces scénarios, en particulier les modules croisés avec des liaisons différentes, peuvent devenir complexes. L’une des principales raisons est la gestion de la désallocation des métadonnées d’exception ou d’exception dans le RTL. Par exemple, supposons qu’une DLL, qui est entièrement liée statiquement et possède sa propre copie du RTL, lève une exception. Comment un EXE, qui est également lié statiquement avec sa propre copie du RTL, ou est lié dynamiquement mais qui a donc toujours une copie différente du RTL à la DLL, peut gérer la libération de mémoire associée à l’exception?
Pourtant, dans la version 10.4.2, nous gérons ces scénarios et prenons en charge les applications où tous les modules sont liés statiquement, ou tous sont liés dynamiquement. Nous ne prenons pas en charge les exceptions inter-modules dans les mélanges de RTL dynamique / statique au sein d’une même application.
Cela signifie que dans 10.4.2, vous devriez voir un comportement de gestion des exceptions considérablement amélioré et un grand nombre de problèmes de qualité résolus pour les exceptions dans le module, les exceptions inter-modules, où les modules sont tous liés statiquement ou tous dynamiquement, pour OS, C ++ et SEH exceptions, et à la fois sur Win32 et Win64 – une matrice de test massive.
Avec chaque version, nous visons à améliorer régulièrement C ++ Builder, et 10.4.2 est – pourrait-on dire – exceptionnel.