Come gestire le modifiche di progettazione per la deprecazione auto_ptr in C ++ 11?

Stiamo testando una libreria in C ++ 11 (ovvero, -std=c++11). La libreria utilizza auto_ptre questo modello:

Foo* GetFoo()
{
    autoptr<Foo> ptr(new Foo);

    // Initialize Foo
    ptr->Initialize(...);

    // Now configure remaining attributes
    ptr->SomeSetting(...);

    return ptr.release();
}

C ++ 11 obsoleto auto_ptr, quindi vogliamo allontanarci da esso.

Tuttavia, il codice supporta sia C ++ 03 che C ++ 11, quindi non è semplice come lo strappo auto_ptr. Vale anche la pena ricordare che la biblioteca non ha dipendenze esterne. Utilizza C ++ 03; e non usa Autotools, Cmake, Boost, ...

Come dovremmo gestire le modifiche alla progettazione per allontanarci da auto_ptrC ++ 11 mantenendo la compatibilità con C ++ 03?

Per la maggior parte degli aspetti, è std::unique_ptrstato creato un rimpiazzo (ma più sicuro) per la sostituzione std::auto_ptr, quindi dovrebbero esserci pochissime (se presenti) modifiche al codice diverse da (come richiesto) per indirizzare il codice a utilizzare unique_ptro auto_ptr.

Ci sono alcuni modi per farlo (e ognuno viene fornito con il proprio elenco di compromessi) di seguito. Dato l'esempio di codice fornito, preferirei una delle prime due opzioni .

opzione 1

#if __cplusplus >= 201103L
template <typename T>
using auto_ptr = std::unique_ptr<T>;
#else
using std::auto_ptr;
#endif

compromessi;

• Introduci il auto_ptrnome nello spazio dei nomi globale; puoi mitigarlo definendo che è il tuo spazio dei nomi "privato"
• Una volta auto_ptreseguita la migrazione a C ++ 17 (credo che verrà completamente rimosso) è possibile cercare e sostituire più facilmente

opzione 2

template <typename T>
struct my_ptr {
    #if __cplusplus >= 201103L
    typedef std::unique_ptr<T> ptr;
    #else
    typedef std::auto_ptr<T> ptr;
    #endif
};

compromessi;

• Probabilmente più ingombrante con cui lavorare, tutta l'attuale auto_ptrnecessità di cambiare il codice in qualcosa del generemy_ptr<T>::ptr
• Migliore sicurezza, i nomi non vengono introdotti nello spazio dei nomi globale

Opzione 3

Un po 'controverso, ma se sei pronto a sopportare le avvertenze di avere una stdclasse come base

#if __cplusplus >= 201103L
template <typename T>
using my_ptr = std::unique_ptr<T>;
#else
template <typename T>
class my_ptr : public std::auto_ptr<T> {
  // implement the constructors for easier use
  // in particular
  explicit my_ptr( X* p = 0 ) : std::auto_ptr(p) {}
};
#endif

compromessi;

• Non tentare di utilizzare la classe ereditata in cui ci si aspetterebbe una base virtuale (in particolare il distruttore non virtuale). Non che questo dovrebbe essere un problema nel caso, ma attenzione
• Ancora una volta, il codice cambia
• Potenziali disallineamenti dello spazio dei nomi: tutto dipende da come la classe puntatore viene utilizzata per iniziare

Opzione 4

Avvolgere i puntatori in una nuova classe e aggregare le funzioni richieste al membro

template <typename T>
class my_ptr { // could even use auto_ptr name?
  #if __cplusplus >= 201103L
  std::unique_ptr<T> ptr_;
  #else
  std::auto_ptr<T> ptr_;
  #endif

  // implement functions required...
  T* release() { return ptr_.release(); }
};

compromessi;

• Un po 'estremo quando tutto ciò che vuoi veramente è "scambiare" le implementazioni

Opzione 5: alias diretto.

#if __cplusplus >= 201103L
template<typename T> 
using MyPtr = std::unique_ptr<T>;
#else 
#define MyPtr std::auto_ptr
#endif 

compromessi:

1. Per le versioni linguistiche più recenti, AKA C ++ 11 e versioni successive, il tipo di alias è associato al puntatore intelligente corretto. Qualsiasi codice utente che in realtà dipende dalle API specifiche di std :: auto_ptr verrà contrassegnato dal compilatore, che è la massima garanzia che verrà realmente corretto.

2. In modalità c ++ 03 legacy il tipo alias è una macro. Questo è grossolano, ma la sintassi risultante MyPtr<T>sarà identica al caso C ++ 11 per tutto il resto del codice.

3. Devi trovare e modificare tutte le tue variabili auto_ptr MyPtrper impostarle.