Quanto è aggressivo cambiare il puntatore intelligente interno a unique_ptr?

Questo è un problema comune per i manutentori del codice vecchio / precedente e non esiste una risposta perfetta. Prima di prendere la decisione di sostituire il codice di lavoro, vorrei proporre di rispondere a queste tre domande.

1. È possibile? Puoi escogitare un metodo in cui le istanze esistenti della "vecchia maniera" possono essere sostituite in modo affidabile dal "nuovo modo" in modo tale che ogni modifica sia garantita per essere eseguita correttamente, per essere testata e superare tutti i test e che non ci saranno nuovi bug essere introdotto?

2. C'è un vantaggio? Riesci a identificare qualsiasi aspetto del codice che sarà migliore dopo aver apportato questa modifica? Il codice sarà più veloce / più piccolo / più gestibile in seguito al cambiamento? La modifica farà scoprire bug che non conoscevi? Il beneficio è abbastanza grande?

3. Abilita? Questo codice è in fase di sviluppo attivo e c'è qualche altro insieme pianificato di modifiche che diventa possibile / più facile / più sicuro come risultato del primo fare questo cambiamento (che compenserebbe il rischio di introdurre bug e la mancanza di un vantaggio diretto)? O si tratta di una base di codice matura e stabile che deve essere protetta da manomissioni da parte di nuovi entusiasti?

Quest'ultimo è spesso il decisore. Se ci sono grandi cambiamenti in avanti per questo codice, eliminare gli ostacoli come i modelli di birra fatta in casa potrebbe essere giustificato, altrimenti è meglio lasciar riposare i cani che dormono.

Il vantaggio principale di fare questa sostituzione sarebbe il costo di portare nuove persone.

Se introduci un nuovo programmatore C ++, hanno per imparare i particolari e i capricci del tuo puntatore intelligente. Considerando che se hai usato unique_ptr , c'è una ragionevole possibilità che conoscano già le sue peculiarità. E se non lo fanno, allora c'è un'intera Internet di informazioni a riguardo. Questa è una delle cose che rende buoni i vocaboli: tutti sanno già come funzionano e, in caso contrario, le informazioni sono prontamente disponibili.

Hai detto che il tuo puntatore intelligente ha strutture di codice speciali progettate per interagire con altre classi specifiche. Questo rappresenta una conoscenza di dominio non banale che gli utenti di quel puntatore intelligente devono sapere. Tale conoscenza di dominio non deve essere acquisita solo da nuovi programmatori, questa conoscenza sarà per la maggior parte inutile al di fuori del tuo progetto.

Considerando che il tempo speso per capire unique_ptr sarà prezioso rispetto alla carriera del C ++.

Questo non vuol dire che devi necessariamente apportare la modifica. Ma questo sarebbe il vantaggio principale nel farlo.

Questo è un problema per molti sistemi legacy. Da un lato, questa capacità personalizzata di std::unique_ptr è in circolazione da molto tempo. Gli insetti sono stati strizzati molto tempo fa e le persone sul progetto sanno come usarli. "Non è rotto, quindi non aggiustarlo".

D'altra parte, è rotto in un certo senso. Una delle maggiori sfide che si pongono di fronte alle soluzioni più vecchie per alcuni problemi è la competizione che ha emulato ciò che hai fatto, ma lo hai fatto usando tecniche moderne. Questa competizione ti supererà se non migliorerai continuamente i tuoi processi e il tuo prodotto. Questa capacità personalizzata di std::unique_ptr è probabilmente una delle molte tecniche del tuo ventennale sistema che, sebbene innovative nel loro tempo, sono ora arcaiche, ingombranti e rallentano il tuo processo di sviluppo.