Jak obsłużyć zmiany w projekcie dla wycofania auto_ptr w C ++ 11?

Testujemy bibliotekę pod C ++ 11 (tj -std=c++11.). Biblioteka korzysta z auto_ptrtego wzoru:

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

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

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

    return ptr.release();
}

C ++ 11 jest przestarzałe auto_ptr, więc chcemy się od niego odejść.

Jednak kod obsługuje zarówno C ++ 03, jak i C ++ 11, więc nie jest to takie proste jak szarpanie auto_ptr. Warto również wspomnieć, że biblioteka nie ma zewnętrznych zależności. Używa C ++ 03; i nie używa Autotools, Cmake, Boost, ...

Jak powinniśmy poradzić sobie ze zmianami w projekcie, aby odejść auto_ptrdla C ++ 11, zachowując zgodność z C ++ 03?

W większości względami std::unique_ptrpowstał być spadek (ale bezpieczniej) zamiennik std::auto_ptr, więc nie powinno być bardzo niewiele (jeśli w ogóle) wymaga zmiany kodu innego niż (jak pytasz) kierowanie kod do używania albo unique_ptralbo auto_ptr.

Istnieje kilka sposobów, aby to zrobić (i każdy ma swoje własne kompromisy listy) poniżej. Biorąc pod uwagę przykładowy kod, wolałbym jedną z dwóch pierwszych opcji .

opcja 1

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

Kompromisy;

• Wprowadzasz auto_ptrnazwę do globalnej przestrzeni nazw; możesz to złagodzić, definiując swoją własną „prywatną” przestrzeń nazw
• Po migracji do C ++ 17 (uważam, że auto_ptrzostanie całkowicie usunięty) możesz łatwiej wyszukiwać i zamieniać

Opcja 2

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

Kompromisy;

• Prawdopodobnie bardziej kłopotliwa w pracy, cała obecna auto_ptrpotrzeba zmiany w kodzie na coś podobnegomy_ptr<T>::ptr
• Dla większego bezpieczeństwa nazwy nie są wprowadzane do globalnej przestrzeni nazw

Opcja 3

Nieco kontrowersyjne, ale jeśli jesteś gotowy pogodzić się z zastrzeżeniami dotyczącymi posiadania stdklasy jako podstawy

#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

Kompromisy;

• Nie próbuj używać odziedziczonej klasy, w której spodziewana byłaby wirtualna baza (w szczególności nie-wirtualny destruktor). Nie to powinno być problemem w tej sprawie - ale pamiętaj o tym
• Ponownie zmiany kodu
• Potencjalne niedopasowania przestrzeni nazw - wszystko zależy od tego, w jaki sposób używana jest klasa wskaźnika

Opcja 4

Zawiń wskaźniki w nową klasę i agreguj wymagane funkcje do elementu członkowskiego

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(); }
};

Kompromisy;

• Trochę ekstremalne, gdy wszystko, czego naprawdę chcesz, to „zamienić” implementacje

Opcja 5: Bezpośredni alias.

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

Kompromisy:

1. W przypadku nowszych wersji językowych, AKA C ++ 11 i nowszych, alias jest odwzorowywany na poprawny inteligentny wskaźnik. Każdy kod użytkownika, który faktycznie zależy od API specyficznych dla std :: auto_ptr, zostanie oflagowany przez kompilator, co jest ostateczną gwarancją, że naprawdę zostanie naprawiony.

2. W trybie Legacy c ++ 03 alias typu to makro. Jest to obrzydliwe, ale wynikowa składnia MyPtr<T>będzie identyczna jak w przypadku C ++ 11 w pozostałej części kodu.

3. Musisz znaleźć i zmienić wszystkie zmienne auto_ptr na MyPtr, aby to skonfigurować.