No ano passado (já se passou quase um ano inteiro), no entanto, mudamos para a nova versão do Boost-1.65.1 e, sob o capô, você encontrará os três bugs que encontramos. Também é importante mencionar que antes disso, o boost -1.62.1 era usado em nosso software, pois alguns bugs apareceram no boost antes da versão 1.65.1
Nosso projeto possui uma equipe de integração especial, cuja principal tarefa é migrar todo o software para uma nova versão de bibliotecas, Visual Studio, novas versões de componentes de baixo nível (básico, dos quais a maioria dos outros componentes depende), etc. A equipe de integração também é responsável por eliminar todos os problemas que surgem, naturalmente com a assistência dos mantenedores de componentes, se necessário. Então, bugs dos quais me lembro especialmente.
Bug in boost :: sistema de arquivos
Este bug veio à tona com rapidez suficiente. Os testes começaram a falhar com "Violação de acesso" ao procurar o caminho completo para o nome do arquivo fornecido. A função fez uma chamada para impulsionar :: sistema de arquivos :: existir e o programa travou. Executando mais alguns testes, vários casos semelhantes foram notados, enquanto em todos os casos a chamada para boost :: filesystem :: exist foi feita para variáveis globais. Aparentemente, algo mudou durante a vida útil das variáveis de impulso. Um
ticket para um bug detectado é muito fácil de pesquisar no google:
ticket :: boost :: filesystem :: existDescobriu-se que esse bug entrou no impulso, começando com a versão 1.64. Na verdade, o problema estava na chamada make_permissions (usada no sistema de arquivos :: exist). Em 1.64, a implementação de make_permissions foi alterada e agora usa variáveis globais, o que significa que quando é feita uma tentativa de chamar o sistema de arquivos :: exist ao inicializar uma variável ou objeto global, as variáveis globais usadas em make_permissions ainda não podem ser inicializadas. Portanto, uma tentativa de acessar uma variável indefinida lança uma exceção.
Solução alternativaPara testes em que variáveis globais foram usadas apenas uma vez, elas foram transferidas para os testes correspondentes e se tornaram variáveis locais. Nem pergunte por que isso não foi feito antes, eu não sou o mantenedor deste código.
Em outros casos,
singelones foram usados.
Bug in boost :: python
Nos testes usando boost :: python, uma coisa estranha foi descoberta. Quando você faz uma chamada trivial para eval () para um literal (por exemplo, "40 + 2"), todas as regras. E se você definir as variáveis e depois usá-las em expressões, receberemos uma mensagem de que os cálculos usam variáveis indefinidas (ERRO: [nome] não definido). Para resolver esse problema, passei mais tempo. Não consegui encontrar um tíquete para esse problema no rastreador de impulso, então tive que pedir ajuda à equipe desse componente. Informações sobre o bug foram rapidamente encontradas
no github .
Aconteceu que na implementação do eval, os objetos globais e locais não foram utilizados. Depois de desejar
boa sorte em encontrar uma correção sem recompilar o código-fonte, a equipe se despediu :)
Solução alternativaMas então me lembrei das
notas de lançamento do boost-1.65.1 e definitivamente havia algo para o boost :: python.
Viva, existe um caminho! O bug foi permitido ao adicionar uma nova implementação de eval com suporte ao argumento char const *, que agora é chamado na antiga implementação de eval com um argumento de string (especialmente cuidadosos podem notar a chamada para essa função no código via link do github). E o novo recurso deveria funcionar.
boost :: numpy
Esta é a minha parte menos favorita. O boost :: python :: numeric foi removido e agora o boost :: python :: numpy apareceu como uma alternativa. Mas o código que usou numérico teve que ser redesenhado praticamente, porque o objetivo não era apenas renomear o espaço para nome, mas também implementar os objetos.
Além disso, houve informações erradas no cabeçalho do impulso que me enganaram.
De acordo com o comentário na fonte, a chamada import_array () já é feita em numpy :: initialize ():
namespace boost { namespace python { namespace numpy { BOOST_NUMPY_DECL void initialize(bool register_scalar_converters=true); }}}
Mas, de fato, como se viu, import_array () é necessário.
Além disso, houve problemas ao testar as alterações, porque os trechos de código com numpy (anteriormente com boost :: python :: numeric) não eram cobertos por testes e o próprio código também era usado em outro componente. Portanto, os problemas foram identificados apenas ao testar o componente correspondente. A equipe de integração não é obrigada a escrever testes para os componentes, e essa situação foi uma omissão da própria equipe. Uau, eu ouvi o suficiente deles que eu quebrei o código deles. Mas depois que a equipe resmungou, eles finalmente cobriram seu código com testes. No entanto, o ressentimento permaneceu (durante a próxima migração, a equipe não quis dar acesso ao seu componente ao meu colega, mencionando que a última vez que quebramos o código para eles.
Sasha, soryan! Mas, depois de três dias de negociações, eles desistiram).
Conclusão
Após o trabalho realizado, posso observar as vantagens para mim, uma vez que o impulso não havia sido usado com muita frequência antes (principalmente o std), de modo que muita migração pode ser enfatizada. É engraçado, mas o fato é que, após esse motivo, por algum motivo você se torna um “especialista em incentivos” para muitos colegas e, concilie, você será questionado sobre isso por mais algum tempo.
A propósito, nos últimos anos, muitas empresas começaram a se livrar ativamente do impulso e a substituir a biblioteca std, se possível, ou qualquer outra coisa na ausência de recursos na biblioteca padrão. E nós também não ficamos de lado. O processo foi iniciado, mas não concluído, ainda há muito trabalho.