返回原始指针而不是unique_ptr是好的编码习惯吗？

Question

I've been studying unique_ptr and decided to write some simple code to make sure I've understood the concept and on how to use it. What I have below is a Manager class, which has a deque that contains unique_ptrs.

  class BaseClass
 {
    //...
 };

class Manager
{

public:

    std::list<BaseClass*> TempFuncName(Random Parameter)
    {
        std::list<BaseClass*> FoundObjects;

        for (ClassType::const_iterator iter(m_deque.begin()); iter != m_deque.end(); ++iter)
        {
            if(/*Do some checks using iter*/)
            {
                FoundObjects.push_back(iter->get());
            }
        }

        return FoundObjects;
    }

private:

    typedef std::deque<std::unique_ptr<BaseClass>> ClassType;
    ClassType m_deque;
};

So basically TempFuncName() will return a list of BaseClass pointers that satisfies some conditions. I've originally thought of having the TempFuncName return a list of unique_ptrs, but I felt that defeats the whole purpose of using unique_ptrs. So instead, I get the raw pointers of the unique_ptr and push_back() those raw pointers into the list and return that list.

I was just wondering if what I am doing (returning raw pointers instead of unique_ptrs) is actually good coding practice, or if it is okay to just return unique_ptrs (which I dont think is a good idea since) or if I shouldnt even use unique_ptrs in this situation.

I've tried googling but a lot of the posts I found didnt really discuss this particular question I had.

Any help and information would be greatly appreciated.

Answer 1

Using raw owning pointer is bad practice.

Using raw observer pointer is fine... but as existing code might use Raw owning pointers, raw pointer is ambiguous between observer pointer and owning pointer.

Types such as std::experimental::observer_ptr<T> have been introduced to express intend clearly. (but it is basically just a pointer).

Observer pointers don't own data, so lifetime of the data should be longer than Observer pointer.

In your case, possible choices include:

class Manager
{
public:
    std::vector</*const*/ T*> filter_view_1(/**/) /*const*/;
    std::vector<std::experimental::observer_view</*const*/T>> filter_view_2(/**/) /*const*/;
    std::vector<std::reference_wrapper</*const*/T>> filter_view_3(/**/) /*const*/;


private:
    std::vector<std::unique_ptr<T>> data;
};

So returned values should be used before that Manager::data is "cleaned".

Or, to guaranty lifetime:

class Manager
{
public:
    std::vector<std::shared_ptr</*const*/T>> filter_view_4(/**/) /*const*/;
    std::vector<std::weak_ptr</*const*/T>> filter_view_5(/**/) /*const*/;


private:
    std::vector<std::shared_ptr<T>> data;
};

filter_view_4 extend lifetime whereas filter_view_5 allows to check lifetime of object.

There are also different approaches to not expose internal, such as:

class Manager
{
public:
    // std::function might be replaced by template for the Functor
    void for_each_filtered(std::function<bool(const T&)> filter,
                           std::function<void(/*const*/ T&)> action) /*const*/
    {
        for (auto& d : data) {
            if (filter(*d)) {
                action(*d)
            }
        }
    }

private:
    std::vector<std::unique_ptr<T>> data;
};

Answer 2

Is returning a raw pointer instead of unique_ptr good coding practice?

No. And yes. There is no answer, because it depends on context. It is fairly simple however:

Transferring ownership of a resource with a raw pointer is a bad coding practice.

Returning a non-owning pointer is a good practice (although in some cases a reference might be better).

These considerations are true in general, and remain true in your particular example. You must consider whether you intend to keep the objects within Manager or are you intending to transfer the ownership to the caller. You haven't removed the unique pointers in the function, so it appears that your intention is to not transfer the ownership. On the third hand, if you intend to share the ownership, then you need to use shared pointers throughout.

Answer 3

Let's go through some options of what you can return

If you return unique_ptr s, then by definition those objects are no longer being managed by the manager. It sounds like they still should be, so unique_ptr is not the right type.

If you return shared_ptr s, or weak_ptr s, then you can be sure that later changes by the manager won't suddenly invalidate your values. Either will mean that you change the queue to shared_ptr .

If you know for sure that these objects exist, for example because the if filtered out nulls, it would be really nice to return BaseClass & s. The problem is that you can't have a reference as the value_type of a container. In that case I would use std::reference_wrapper<BaseClass> as the contents of your container, although BaseClass * isn't much worse, as reference_wrapper is basically a pointer anyway.

If a null pointer is a valid option to return, you can't use references, so BaseClass * may be your best option.