El año pasado (ya ha pasado casi un año entero), sin embargo, cambiamos a la nueva versión de Boost-1.65.1, y debajo del capó encontrará los tres errores de impulso que encontramos. También es importante mencionar que antes de eso, se utilizó boost -1.62.1 en nuestro software, ya que algunos errores aparecieron en boost antes que la versión 1.65.1
Nuestro proyecto tiene un equipo de integración especial, cuya tarea principal es migrar todo el software a una nueva versión de bibliotecas, Visual Studio, nuevas versiones de componentes de bajo nivel (básico, del que dependen la mayoría de los otros componentes), etc. El equipo de integración también es responsable de eliminar todos los problemas que surjan, naturalmente con la ayuda de los encargados de mantenimiento de componentes, si es necesario. Entonces, errores que recuerdo especialmente.
Error en boost :: sistema de archivos
Este error salió a la superficie lo suficientemente rápido. Las pruebas comenzaron a fallar con "Infracción de acceso" al buscar la ruta completa al nombre de archivo dado. La función hizo una llamada para impulsar :: filesystem :: exist, y el programa se bloqueó. Al ejecutar algunas pruebas más, se notaron varios casos similares más, mientras que en todos los casos se realizó la llamada boost :: filesystem :: exist para variables globales. Aparentemente, algo ha cambiado en la vida útil de las variables de impulso. Un
ticket para un error detectado es muy fácil de buscar en Google
un ticket de error en boost :: filesystem :: existResultó que este error aumentó, comenzando con la versión 1.64. En realidad, el problema estaba en la llamada make_permissions (utilizada en el sistema de archivos :: exist). En 1.64, la implementación de make_permissions se modificó y ahora usa variables globales, lo que significa que cuando se intenta llamar al sistema de archivos :: existe al inicializar una variable u objeto global, las variables globales utilizadas en make_permissions aún no se pueden inicializar. Por lo tanto, un intento de acceder a una variable indefinida genera una excepción.
Solución alternativaPara las pruebas donde las variables globales se usaron solo una vez, se transfirieron a las pruebas correspondientes y se convirtieron en variables locales. Ni siquiera pregunte por qué esto no se ha hecho antes, no soy el encargado de mantener este código.
En otros casos,
se usaron
singletones .
Error en boost :: python
En las pruebas con boost :: python, se descubrió algo extraño. Cuando realiza una llamada trivial a eval () para un literal (por ejemplo, "40 + 2"), todas las reglas. Y si define las variables y luego las usa en expresiones, recibimos un mensaje de que los cálculos usan variables indefinidas (ERROR: [nombre] no definido). Para resolver este problema, pasé más tiempo. No pude encontrar un boleto para este problema en el rastreador de impulso, así que tuve que pedir ayuda al equipo de este componente. La información sobre el error se encontró rápidamente
en github .
Sucedió que en la implementación de eval, los objetos globales y locales no fueron utilizados. Después de haber deseado
buena suerte para encontrar una solución sin volver a compilar el código fuente, el equipo se despidió :)
Solución alternativaPero luego recordé las
notas de la versión de boost-1.65.1 y definitivamente había algo allí para boost :: python.
¡Hurra, hay un camino! El error se permitió al agregar una nueva implementación de eval con soporte para el argumento char const *, que ahora se llama en la implementación anterior de eval con un argumento de cadena (los que sean especialmente cuidadosos podrían notar la llamada a esta función en el código a través de un enlace github). Y se esperaba que la nueva característica funcionara.
impulso :: numpy
Esta es mi parte menos favorita. boost :: python :: numeric ha sido eliminado y ahora boost :: python :: numpy ha aparecido como alternativa. Pero el código que usaba numérico tuvo que ser rediseñado más o menos, porque el punto no era solo cambiar el nombre del espacio de nombres, sino también implementar los objetos.
Además, había información errónea en el encabezado de impulso que me llevó por mal camino.
Según el comentario en la fuente, la llamada a import_array () ya está hecha en numpy :: initialize ():
namespace boost { namespace python { namespace numpy { BOOST_NUMPY_DECL void initialize(bool register_scalar_converters=true); }}}
Pero, de hecho, resultó que import_array () es necesario.
Además, hubo problemas con la prueba de los cambios, porque las pruebas no cubrieron en absoluto los fragmentos de código con numpy (anteriormente con boost :: python :: numeric), y el código en sí también se usó en otro componente. Por lo tanto, los problemas se identificaron solo al probar el componente correspondiente. El equipo de integración no está obligado a escribir pruebas para los componentes, y esta situación fue una omisión del propio equipo. Wow, escuché suficiente de ellos como para romper su código. Pero después de que el equipo se quejó, finalmente cubrieron su código con pruebas. Sin embargo, el resentimiento se mantuvo (durante la próxima migración, el equipo no quiso dar acceso a su componente a mi colega, mencionando que la última vez que les rompimos el código.
Sasha, soryan! Pero después de tres días de negociaciones se dieron por vencidos).
Conclusión
Después del trabajo realizado, puedo notar las ventajas para mí mismo, ya que el refuerzo no se había usado con mucha frecuencia antes (principalmente estándar), por lo que se puede enfatizar mucho en la migración. Es gracioso, pero el hecho es que, después de tal razón, por alguna razón usted no se convierte en un "experto en impulso" para muchos colegas, y, reconciliarse, se le harán preguntas al respecto por un tiempo más.
Por cierto, en los últimos años, muchas compañías comenzaron a deshacerse activamente del impulso y reemplazar la biblioteca estándar si es posible, o algo más en ausencia de características en la biblioteca estándar. Y nosotros tampoco nos hicimos a un lado. El proceso se inicia, pero no se completa, todavía hay mucho trabajo.