正在使用 std::vector&lt; std::shared_ptr<const T> &gt; 反模式？

Question

For a long time I was using std::vector and std::shared_ptr hand in hand. Recently I started using std::shared_ptr<const T> whenever a pointer to a const object was needed. This is all OK, since std::shared_ptr<T> can be cast to std::shared_ptr<const T> and then they share the same reference counter and everything feels natural.

But when I try to use constructs such as std::vector< std::shared_ptr<const T> > I run into troubles. To simplify I will denote the two structures:

template <class T>
using SharedPtrVector = std::vector< std::shared_ptr<T> >;

template <class T>
using SharedConstPtrVector = std::vector< std::shared_ptr<const T> >;

The problem is that although SharedPtrVector and SharedConstPtrVector are very similar, SharedConstPtrVector cannot be cast to SharedPtrVector .

So each time I want to be a const correct and write a function such as:

void f(const SharedConstPtrVector<T>& vec);

there is no way I can pass const SharedPtrVector<T> to f .

I was thinking about this a lot and considered several alternatives:

1. Write conversion functions

   template <typename T> SharedConstPtrVector<T> toConst(const SharedPtrVector<T>&);

2. Write code in generic form:

    template <typename T> void f(const std::vector< std::shared_ptr<T> >& vec);

   or

   template <typename TIterator> void f(TIterator begin, TIterator end);

3. Abandon the idea of std::vector< std::shared_ptr<const T> >

The problem with 1. is the computational overhead and increased uglyness of code, while 2. gives the code an "everything is a template" flavor.

I am an inexperienced programmer and I don't want to set out in the wrong direction. I would like to hear advice from someone who has experience with this problem.

Answer 1

I would suggest reviewing your design with a view to establish a clear owner of those object. This is the absence of clear ownership that lead people to use shared smart pointers.

Bjarne Stroustrup recommends using smart pointers only as a last resort. His recommendations (best to worst) are:

1. Store an object by value.
2. Store many objects in a container by value.
3. If nothing else works, use smart pointers.

See Bjarne Stroustrup - The Essence of C++: With Examples in C++84, C++98, C++11, and C++14 at 0:37:40.

Answer 2

1 The problem is not related to shared_ptr<> , but occurs already for ordinary pointers:

template<typename T>
void foo(std::vector<const T*>);

int a,b;
std::vector<int*> bar={&a,&b};
foo<???>(bar);        // no value for ??? works

2 The construct vector<shared_ptr<T>> is sensibly only iff there is no owner to the objects hold.

Answer 3

It is a valid way of storing immutable (and thus thread safe) objects, a building block for a per-element copy-on-write cache. Definitely not an anti-pattern.

Answer 4

if you insist on keeping std::vector you can try to encapsulate it into a handle-body idiom structure.

this allows you to keep a non const shared pointer in a const handle.

Answer 5

If I am storing thousands of 3d points (eg in a std::vector) and want to push the address of those entries into another structure (say a heap for sorting or other purposes) and the secondary structure might need to delete some of those entries (eg values closer than the stated accuracy of the sensor), who is the 'owner'? It seems like the best solution is a vector of smart pointers, exactly what Stroustrup suggests should be the last resort, with the points themselves allocated on the heap?