Lanzamiento de calidad
C ++ Builder 10.4.2 trae algunas características geniales que creemos que realmente lo ayudarán, la más grande es ‘ split DWARF ‘, una forma de reducir el uso de memoria en el vinculador al eliminar la información de depuración. Si tiene proyectos que superan los límites del vinculador, compruébelo: puede resolver sus problemas (consulte esta publicación de blog ). Sin embargo, RAD Studio 10.4.2 en general también fue en gran medida una ‘versión de calidad’. De hecho, a pesar de que 10.4.1 es la versión dirigida a la calidad y 10.4.2 a las características que necesita, ¡solucionamos más problemas en 10.4.2 que en 10.4.1!
Y C ++ Builder no es una excepción.
Manejo de excepciones de C ++
Este maravilloso juego de palabras presenta el trabajo de manejo de excepciones que hicimos en 10.4.2. Si es demasiado largo, aquí está el TLDR: 10.4.2 brinda a sus aplicaciones una estabilidad muy alta y un comportamiento más correcto al manejar excepciones.
Analizamos las categorías de informes de problemas que recibimos y también hacemos mucho trabajo que nos ayuda a encontrar problemas internamente. Parte de ese trabajo se realiza mediante el soporte de bibliotecas de C ++ : el uso de código externo es una buena manera de garantizar que nuestra cadena de herramientas sea compatible. Debido a esos análisis, en 10.4.2 revisamos gran parte de nuestro manejo de excepciones para Windows.
Los escenarios que analizamos son:
- Excepciones en el módulo , cuando se lanza una excepción y se captura en el mismo binario, como todo dentro de un EXE.
- Excepciones entre módulos , cuando una excepción cruza el límite de un módulo, como ser lanzada en una DLL pero atrapada en un EXE. Esta es una situación más difícil de manejar, y las pautas de codificación indican que no se deben filtrar excepciones de un módulo a otro … pero vemos código donde esto ocurre y es un escenario importante a abordar. Es común con los paquetes, o cuando se combinan varios archivos DLL y un EXE como una aplicación.
- Excepciones entre lenguajes , cuando una excepción cruza marcos de pila que pertenecen tanto a Delphi como a C ++. Las excepciones pueden plantearse en un idioma y detectarse en otro, o cruzar el límite varias veces.
- Cuando todos los módulos (por ejemplo, un EXE y DLL) están vinculados estáticamente , o todos los módulos están vinculados dinámicamente (RTL dinámico).
- Excepciones de OS, C ++ y SEH
- Ambas plataformas Win32 y Win64 .
Muchos de estos escenarios, especialmente los de módulos cruzados con diferentes enlaces, pueden volverse complejos. Una de las principales razones es manejar la desasignación de una excepción o metadatos de excepción en el RTL. Por ejemplo, supongamos que una DLL, que está completamente vinculada estáticamente y tiene su propia copia de RTL, lanza una excepción. ¿Cómo puede un EXE, que también está vinculado estáticamente con su propia copia de RTL, o está vinculado dinámicamente, pero por lo tanto todavía tiene una copia diferente de RTL a la DLL, manejar la liberación de memoria asociada con la excepción?
Sin embargo, en 10.4.2 manejamos esos escenarios y admitimos aplicaciones en las que todos los módulos están vinculados estáticamente o todos están vinculados dinámicamente. No admitimos excepciones entre módulos en mezclas de RTL dinámicas / estáticas dentro de una aplicación.
Esto significa que en 10.4.2 debería ver un comportamiento de manejo de excepciones significativamente mejorado y una gran cantidad de problemas de calidad resueltos para excepciones en el módulo, excepciones entre módulos, donde los módulos están todos vinculados estáticamente o dinámicamente, para OS, C ++ y SEH excepciones, y en Win32 y Win64, una matriz de prueba masiva.
Con cada lanzamiento, nuestro objetivo es mejorar constantemente C ++ Builder, y se podría decir que 10.4.2 es excepcional.