How to handle design changes for auto_ptr deprecation in C++11?

Question

We are testing a library under C++11 (i.e., -std=c++11). The library uses auto_ptr and this pattern:

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

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

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

    return ptr.release();
}

C++11 deprecated auto_ptr, so we want to move away from it.

However, the code supports both C++03 and C++11, so its not a simple as yanking auto_ptr. It's also worth mentioning the library has no external dependencies. It uses C++03; and does not use Autotools, Cmake, Boost, ...

How should we handle the design changes to move away from auto_ptr for C++11 while retaining compatibility with C++03?

Answer 1

In most respects the std::unique_ptr was made to be drop in (but safer) replacement for std::auto_ptr, so there should be very few (if any) code changes required other than (as you ask) directing the code to use either unique_ptr or auto_ptr.

There a few ways to do this (and each comes with its own list tradeoffs) below. Given the code sample provided, I would favour either of the first two options.

Option 1

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

Tradeoffs;

• You introduce the auto_ptr name into the global namespace; you can mitigate this by defining it in your own "private" namespace
• Once you migrate to C++17 (I believe auto_ptr will be completely removed) you can more easily search and replace

Option 2

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

Tradeoffs;

• Probably more cumbersome to work with as all the current auto_ptr references need to be changed in the code to something like my_ptr<T>::ptr
• Better safety because the names are not being introduced into the global namespace

Option 3

Somewhat controversial, but if you are prepared to put up with the caveats of having a std class as a 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

Tradeoffs;

• Don't try to use the inherited class where a virtual base (in particular w.r.t. the non-virtual destructor) would be expected. Not that this should be an issue in the case - but be aware of it
• Again, code changes
• Potential namespace mismatches - it all depends on how the pointer class is used to begin with

Option 4

Wrap the pointers in a new class and aggregate the required functions to the member

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

Tradeoffs;

• A little extreme when all you really want is to "swap" the implementations out

Answer 2

Option 5: Direct alias.

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

Tradeoffs:

1. For newer language versions, AKA C++11 and later, your alias type maps to the correct smart pointer. Any user code that actually depends on APIs specific to std::auto_ptr will get flagged by the compiler, which is the ultimate guarantee that it'll really be fixed.

2. In Legacy c++03 mode the type alias is a macro. This is gross, but the resulting syntax MyPtr<T> will be identical to the C++11 case throughout the rest of the code.

3. You have to find and change all your auto_ptr variables to MyPtrin order to set this up.

Answer 3

“deprecated” means you can still use it if you have a good reason. Having to support an older compiler version is a good reason. I would work until a decision is made that development for cxx03 is stopped and no new development will work with 03. And you have that in writing by your management.

At that point you rip out the old code and replace it with new code. And if someone complains you show them the written statement.