C++ Storing a shared object but not taking ownership

Question

I have a situation where I have a piece of hardware and it really only makes sense for a single connection to be open on that hardware at the same time, so I really only want to refer to one object no matter where it's passed. So it may look something like:

class Hardware {
public:
   void Open(); //this will create and launch a connection monitor in the background
   void Close();
   std::string SendPing();
   std::string AskForSomeOtherData();
   bool isConnected();
   bool setConnected(bool connState);
private:
   bool connected_;
   int hndl_;
}

I then have another class monitoring the connection in the background so my UI can be notified if a connection is lost.

class ConnectionMonitor{
    ConnectionMonitor(Hardware& hw);
    void Run(); //launches a background thread to send "pings" to the device to make sure it's there. Will update Hardware.connected_
    Hardware hw_; //or Hardware* hw_, or shared_ptr<Hardware> hw_, or Hardware& hw_;
}

When the connection monitor notices a connection is lost, it needs to update the connected boolean of the hardware object passed in directly, because my other threads using the object will also want to know it's been disconnected. But I don't know if updating the private data of the object indicates ownership of the object itself?

I don't believe so, since the lifetime of the object shouldn't be effected. There are all these different ways to pass an object shared between two classes, but I don't know what the problem domain calls for when I need to store it in class private data. Requiring a shared pointer to be passed in is one option. But I am not really indicating any ownership of the object being taken I don't think? A reference seems to be more fitting possibly, but then I end up with needing Hardware& hw; in my ConnectionMonitor private data so I keep a reference to the Hardware object. Then I read stuff that says "Reference in private data bad."

Also, if the caller is storing the hardware object as a shared_ptr, I believe I would have to do something like the following to pass it into my ConnectionMonitor:

ConnectionMonitor(*hardware);

but is this ok for a shared pointer, to dereference it, pass the object to a constructor, and then have the consuming class store another pointer to the same object that the shared pointer owns?

ConnectionMonitor(Hardware& hw){
   Hardware* = hw; //not 100% sure if this syntax is correct, still learning. Most importantly here I'd be taking the hw object being referenced and pointing at it internally, rather than creating a copy
}

It seems now I am now creating a pointer to an object that the shared pointer already owns.

There are a lot of questions embedded above in what amounts to be a brain dump on my thought process, so I will try to summarize. When two threads need access to the same resource, and that resource needs to be updated from either thread, is this a case for a shared pointer? If one of the classes is not taking ownership, what is the best way to store that shared object in private data?

Answer 1

but is this ok for a shared pointer, to dereference it, pass the object to a constructor, and then have the consuming class store another pointer to the same object that the shared pointer owns?

Yes raw pointers are fine when the are non-owning. You can use std::shared_ptr::get to retrieve the stored raw pointer. However, when you store the raw pointer you need to consider the lifetime of the object. For example this is fine:

#include <memory>
#include <iostream>

struct bar {
    std::shared_ptr<int> owning_ptr;
    bar() : owning_ptr(std::make_shared<int>(42)) {}
    ~bar() { std::cout << "bar destructor\n"; }
};
struct foo {
    int* non_owning_ptr;
    ~foo() { std::cout << "foo destructor\n"; }
};


struct foobar {
    bar b;
    foo f;
    foobar() : b(),f{b.owning_ptr.get()} {}
};

int main() {
    foobar fb;
}

b gets initialized first and f can use a pointer to the int managed by owning_ptr. Because f gets destroyed first, there is no danger of f using non_owning_ptr after owning_ptr already deleted the int.

However, only in certain circumstances you can be certain that the raw pointer can only be used as long as the object managed by a smart pointer is alive. As mentioned in a comment, the non-owning counter part to std::shared_ptr is std::weak_ptr. It does not increment the reference count, hence does not prevent the managed object to be deleted when all std::shared_ptrs to the object are gone.

#include <memory>
#include <iostream>

struct moo {
    std::weak_ptr<int> weak;
    void do_something() {
        std::shared_ptr<int> ptr = weak.lock();
        if (ptr) { std::cout << "the int is still alive: " << *ptr << "\n"; }
        else { std::cout << "the int is already gone\n"; }
    }
};


int main() {
    moo m;
    {
        std::shared_ptr<int> soon_gone = std::make_shared<int>(42);
        m.weak = soon_gone;
        m.do_something();
    }
    m.do_something();
}

Output is:

the int is still alive: 42
the int is already gone

As already mentioned the std::weak_ptr does not keep the object alive. Though, it has a lock method that locks the object from being destroyed as long as the returned std::shared_ptr is alive. When lock is called on the weak_ptr when the object is already gone, also the returned shared pointer is empty.

---

When two threads need access to the same resource, and that resource needs to be updated from either thread, is this a case for a shared pointer?

Yes and no. The ref counting of std::shared_ptr is thread safe. Though using a shared pointer does not automagically make the pointee thread safe. You need some synchronization mechanism to avoid data races.