Question

How does one access unique_ptr elements of a container (via an iterator) without taking ownership away from the container? When one gets an iterator to an element in the container is the element ownership still with the container? How about when one dereferences the iterator to gain access to the unique_ptr? Does that perform an implicit move of the unique_ptr?

I find I’m using shared_ptr a lot when I need to store elements in a container (not by value), even if the container conceptually owns the elements and other code simply wishes to manipulate elements in the container, because I’m afraid of not being able to actually access the unique_ptr elements in the container without ownership being taken from it.

Any insights?

Answer 1

As long as you don’t try to make a copy of the unique_ptr, you can just use it. You’ll have to “double dereference” the iterator to get to the pointer’s value, just as you would have to with shared_ptr. Here’s a brief example:

#include <vector>
#include <memory>
#include <iostream>

template <class C>
void
display(const C& c)
{
    std::cout << '{';
    if (!c.empty())
        std::cout << *c.front();
    for (auto i = std::next(c.begin()); i != c.end(); ++i)
        std::cout << ", " << **i;
    std::cout << "}\n";
}

int main()
{
    typedef std::unique_ptr<int> Ptr;
    std::vector<Ptr> v;
    for (int i = 1; i <= 5; ++i)
        v.push_back(Ptr(new int(i)));
    display(v);
    for (auto i = v.begin(); i != v.end(); ++i)
        **i += 2;
    display(v);
}

If you do (accidentally) make a copy of the unique_ptr:

Ptr p = v[0];

then you’ll find out at compile time. It won’t cause a run time error. Your use case is why container<unique_ptr<T>> was built. Things should just work, and if they don’t, the problem appears at compile time instead of run time. So code away, and if you don’t understand the compile time error, then ask another question back here.