Question

I’m using a unique_ptr to pass a const wchar_t pointer to a function. In the following I would like to give a short example:

bool MyClass::foo(unique_ptr<const wchar_t> display_name) {
  bool result = false;
  ....
  // Do something
  result = DoWork(display_name.get());
  ....
  // I have to call release to prevent getting an error
  display_name.release();
  return result;
}

Until now I thought I don’t have to call the release() method of a unique_ptr before leaving the scope (return from function) because the content of the unique_ptr will automatically be deleted if the unique_ptr runs out of scope. But if don’t call the release() method I get the following error (VS 2010):

I think this error message occurs because the memory isn’t correctly freed? What’s the recommended approach dealing with unique_ptr, which is passed as an argument?

Answer 1

Based on your description and comment I believe this is more what you are looking for:

bool MyClass::foo(const std::wstring& display_name)
{
  bool result = false;

  // Do something
  result = DoWork(display_name.c_str());

  return result;
}

This string object is a STL container of wchar_t that has various helpful methods. One of which is c_str() which returns a c-style const wchar_t* version of the string contents for backwards compatibility with older code. Your DoWork function may be such a function that requires a c-style string so the above will work for you.

---

Now onto smart pointers 101:

In C++11 std::unique_ptr can be used to automatically destruct objects allocated on the heap freeing from the worries of exception unsafe code and manual memory management which can lead to memory leaks and other bad things. Say you had the following code:

void LeakyFunction()
{
    double* ptr = new double;
}

Obviously that’s a memory leak as once the scope of LeakyFunction ends we’ve lost the pointer on the stack and no longer can delete what it was pointing to on the heap. So we write this:

void LessLikelyLeakyFunction()
{
    double* ptr = new double;
    // do stuff
    delete ptr; // clean up heap
}

That’s well and dandy unless you have an early return or throw an exception during the do stuff portion of code which puts you back to the same problem as before. So people started writing custom smart pointer classes which owned raw memory allocation by allocating on construction and deallocating on destruction. This concept has now become standard via things like std::unique_ptr so we can do the following:

void SmartFunction()
{
    std::unique_ptr<double> ptr(new double);
    // do stuff
} // unique_ptr is smart and calls delete for you

In this way no matter when the scope of the function ends you don’t have to worry things will be cleaned up properly. In short if you aren’t using new you don’t need a smart pointer and if you are then you probably should use a smart pointer to make your code more robust.