Como alterar agressivamente o ponteiro inteligente interno para unique_ptr?

5

Trabalho em um grande produto de software que, com mais de 20 anos, possui várias construções que foram substituídas por atualizações de idioma.

Uma delas é uma classe de modelo de ponteiro inteligente que age de forma semelhante a - mas não é bastante indentical para - std::unique_ptr . A classe tem seu destruidor especializado para vários tipos com necessidades específicas de destruição e é referenciada da ordem de 150-200 vezes. Aparentemente funciona perfeitamente.

Se o aplicativo fosse escrito do zero agora, estou razoavelmente certo de que std::unique_ptr seria usado em seu lugar. Quão agressivamente devemos buscar a substituição da classe laminada em casa por std::unique_ptr ; possivelmente incluindo typedef s para as especializações comuns com destruidores específicos?

    
por Chowlett 04.04.2016 / 10:50
fonte

3 respostas

5

Este é um problema comum para mantenedores de código antigo / legado, e não há uma resposta única e perfeita. Antes de tomar a decisão de substituir o código de trabalho, proponho tentar responder a essas três perguntas.

  1. É possível? Você pode criar um método pelo qual as instâncias existentes do 'modo antigo' possam ser substituídas de maneira confiável pelo 'novo caminho', de modo que cada alteração tenha a garantia de ser feita corretamente, ser testada e passar em todos os testes e que nenhum novo erro ser introduzido?

  2. Existe algum benefício? Você consegue identificar qualquer aspecto do código que será melhor depois de fazer essa alteração? O código será mais rápido / menor / mais sustentável como resultado da mudança? A mudança irá revelar bugs que você não conhece? O benefício é grande o suficiente?

  3. Está habilitando? Este código está em desenvolvimento ativo e há algum outro conjunto planejado de mudanças que se torna possível / mais fácil / seguro como resultado da primeira mudança (o que compensaria o risco de introduzir erros e a falta de um benefício direto)? Ou esta é uma base de código madura e estável que realmente precisa ser protegida contra adulterações por novatos entusiastas?

Este último é frequentemente o decisivo. Se houver grandes mudanças à frente para esse código, então, se livrar de obstáculos como modelos caseiros pode ser justificado, onde, de outro modo, geralmente é melhor deixar os cães dormindo.

    
por 04.04.2016 / 15:25
fonte
2

A principal vantagem de fazer essa substituição seria o custo de trazer novas pessoas.

Se você trouxer um novo programador C ++, eles terão para aprender os detalhes e os caprichos do seu ponteiro inteligente. Considerando que se você usou unique_ptr , há uma chance razoável de que eles já conhecem suas peculiaridades. E se não, então há toda uma Internet de informações sobre isso. Essa é uma das coisas que torna os tipos de vocabulário bons: todos já sabem como eles funcionam e, caso contrário, as informações estão prontamente disponíveis.

Você menciona que seu ponteiro inteligente possui estruturas de código especiais projetadas para interagir com outras classes específicas. Isso representa o conhecimento de domínio não trivial que os usuários desse ponteiro inteligente precisam saber. Tal conhecimento de domínio não deve ser adquirido apenas por novos programadores, este conhecimento será em sua maior parte inútil fora de seu projeto.

Considerando que o tempo gasto na compreensão de unique_ptr será valioso em relação à carreira de C ++.

Isso não quer dizer que você necessariamente deva fazer a mudança. Mas essa seria a principal vantagem em fazê-lo.

    
por 04.04.2016 / 15:26
fonte
1

Este é um problema para muitos sistemas legados. Por um lado, esse recurso std::unique_ptr personalizado tem sido usado há muito tempo. Bugs foram forçados há muito tempo, e as pessoas no projeto sabem como usá-lo. "Não está quebrado, então não conserte".

Por outro lado, está quebrado em certo sentido. Um dos maiores desafios que as soluções mais antigas enfrentam para alguns problemas é a concorrência que emulou o que você fez, mas o fez usando técnicas modernas. Essa competição irá superá-lo se você não melhorar continuamente seus processos e seu produto. Essa capacidade personalizada de std::unique_ptr é provavelmente uma das muitas técnicas em seu sistema de vinte anos que, embora inovadoras em seu tempo, são agora arcaicas, incômodas e estão retardando seu processo de desenvolvimento.

    
por 04.04.2016 / 13:33
fonte