studio - ¿Alguna mejora en el frente GCC/Windows DLL/C++ STL?

mingw

Question

Ayer, me puse un poco molesto al usar archivos DLL compilados con GCC bajo Cygwin. Básicamente, tan pronto como se ejecuta con un depurador, puede terminar aterrizando en una trampa de depuración causada por RtlFreeHeap () que recibe una dirección a algo que no asignó.

Este es un error conocido con GCC 3.4 en Cygwin. La situación surge porque la biblioteca libstdc ++ incluye una optimización "inteligente" para cadenas vacías. Le evito los detalles (vea las referencias a lo largo de esta publicación), pero cada vez que asigna memoria en un archivo DLL para un objeto std :: string que "pertenece" a otro archivo DLL, termina dando un montón a un montón gratis que vino de otro montón. De ahí el SIGTRAP en RtlFreeHeap () .

Se informan otros problemas cuando se lanzan excepciones entre los límites de la DLL.

Esto hace que GCC 3.4 en Windows sea una solución inaceptable tan pronto como su proyecto se base en DLL y STL. Tengo algunas opciones para pasar esta opción, muchas de las cuales consumen mucho tiempo y / o son molestas:

• Puedo parchar mi libstdc ++ o reconstruirlo con la opción de configuración --enable-fully-dynamic-string
• Puedo usar bibliotecas estáticas en su lugar, lo que aumenta mi tiempo de enlace

No puedo (todavía) cambiar a otro compilador tampoco, debido a algunas otras herramientas que estoy usando. Los comentarios que encuentro de algunas personas del CCG es que "casi nunca se informa, por lo que probablemente no sea un problema", lo que me molesta aún más.

¿Alguien tiene alguna noticia sobre esto? No puedo encontrar ningún anuncio claro de que esto se haya solucionado (el error todavía se marca como "asignado"), excepto un comentario en el rastreador de fallos de GNU Radio .

¡Gracias!

Answer 1

El problema general al que te estás enfrentando es que C ++ nunca fue realmente un lenguaje de componentes. Realmente fue diseñado para ser utilizado para crear aplicaciones completas independientes. Cosas como bibliotecas compartidas y otros mecanismos similares fueron creados por vendedores por su cuenta. Piensa en este ejemplo: supongamos que creaste un componente C ++ que devuelve un objeto C ++. ¿Cómo sabe el componente C ++ que será utilizado por un llamador C ++? Y si la persona que llama es una aplicación de C ++, ¿por qué no utilizar la biblioteca directamente?

Por supuesto, la información anterior en realidad no te ayuda.

En cambio, crearía las bibliotecas / DLL compartidas para que sigas un par de reglas:

1. Cualquier objeto creado por un componente también es destruido por el mismo componente.
2. Un componente puede descargarse con seguridad cuando se destruyen todos sus objetos creados.

Puede que tenga que crear API adicionales en su componente para garantizar estas reglas, pero al seguir estas reglas, se asegurará de que no ocurran problemas como el descrito.