Should I use unique_ptr for a string?

Question

I'm new to C++. I've heard that using unique_ptr / shared_ptr is the "way to go" for references to data allocated on the heap. Does it make sense, therefore, to use unique_ptrs instead of std::strings?

Answer 1

Why would you want to do that?

An std::string object manages the life time of the "contained" string (memory bytes) by itself.

Since you are new to C++. Inside your function / class method, I will advice you create your objects on the stack: Like so:

  std::string s;

as opposed to using the heap:

 std::string* s = new std::string();

Objects created on the stack will be destroyed when your object goes out of scope. So there is no need for smart pointers.

You can following this link to know more: http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/

Answer 2

There's no need to use a std::unique_ptr or std::shared_ptr for a std::string.

You do not have to allocate memory for a simple std::string.

std::string str = "abc";

As simple as that. No need for memory allocation, as the std::string manages the 'real' string by itself.

---

There are situations which may lead to usage of a pointer, though it is likely a class/struct instance.

For instance consider using

std::unique_ptr<MyClass> p;

instead of

MyClass *p;

if possible.

Answer 3

You normally don't need pointers to strings, just like you generally don't need pointers to integers. You can just store string values, you can pass string values, etc.

But if you are in the exceptional situation where you'd need a pointer to a string, then yes, std::unique_ptr<std::string> or std::shared_ptr<std::string> are better than std::string*.

Answer 4

An std::unique_ptr ensures that the object pointed is not accidentally copied and properly deleted. As you should avoid dynamic allocation as much as you can, you can simply keep the std::string as a member of your class. If it is a returned value, as already pointed out, the string class is smart enough to properly move resources in a safe way. You don't need to guarantee that a string is unique, I mean, no copies exist, so the unique ptr is just a too strong constraint. KIS rule: Keep it simple.

Answer 5

Usually, and by default the answer is no, as others have suggested. However - sometimes, the answer may paradoxically be "Possibly Yes"! How come?

• With std::string, you don't control how, when and by whom your buffer is allocated. While this is somewhat mitigated if you use a different allocator (std::basic_string<char, MyAllocatorType>) - the resulting class is not std::string; and will generally not be accepted by functions which taken std::string's. And it may not make sense to get into allocators just for this purpose.
• More specifically, you can allow your unique-pointer-based string class to be created as an owning wrapper for an existing buffer.
• Now that we can use string_view's - and they are even in the standard in C++20 (std::string_view) - you don't have to rewrite the whole string class for unique-pointer-based strings; all you need is to create a string view over it, using the raw pointer and the size in bytes (or size - 1 if you want better null-termination safety.) And if you do want the std::string methods still, they'll be one-liners, e.g.

  std::string_view view() const { 
       return std::string_view{uptr_.get(), size_}; 
  }
  substr(size_type pos = 0, size_type count = npos) const { 
       return view().substr(pos, count); 
  }
  

• If you want to update a string in-place, while maintaining its size - an std::string won't work for you: Either its completely constant, or mutable both in size and in contents.