Inheritance and smart pointers (std::shared_ptr) - c++

Question

There are a lot of things that needs to be said. First off, I would like to know if the approach below is considered a design pattern or even a common technique (That's why I didnt provide further information on the title). If thats the case, whats the name?
Anyways, this is a minified version of what I'm trying to achieve. Since I need to use copying, I found that using std::shared_ptr is the best to avoid deallocated (deleted) pointers.
class Foo
{
public:
Foo() : ptr(nullptr) {}
Foo(const Foo& foo) : ptr(foo.ptr) {}
virtual ~Foo() = default;
void whatever() {
if (ptr)
ptr->whateverHandler();
}
void reset() {
ptr.reset();
}
void resetBar() {
ptr.reset(new Bar);
}
// Other resets here...
protected:
Foo(Foo* foo) : ptr(foo) {}
private:
// Every child class should override this
virtual void whateverHandler() {
throw "whateverHandler cant be called within base class";
}
protected:
std::shared_ptr<Foo> ptr;
};
class Bar : public Foo
{
public:
Bar() : Foo(this) {}
void whateverHandler() {
printf("Bar's handler!!! \n");
}
};
This all looks good and compiles fine, however, the following exame crashes. Why is that?
int main()
{
{
Foo f;
f.resetBar();
}
return getchar();
}

Answer 1

Bar() : Foo(this) {}
Be careful when you pass this to a shared_ptr.
Think about what will happen afterf.resetBar(); and ptr.reset(new Bar); again.
For new Bar, an object of type Bar will be constructed, and inside its constructor this is passed to the parent class member ptr, then the object is managed by the it which is a std::shared_ptr.
After that, the object is managed by f.ptr; which is another std::shared_ptr.
So there're two std::shared_ptrs pointing to the same object, but std::shared_ptrs don't know anything about that; because you're constructing them separately. When f and f.ptr is destroyed, the pointed-to object will be destroyed too. Then the member ptr will be destroyed, it will try to destroyed the same object again, which leads to UB.
I'm not sure about what the design trying to accomplish, but just stopping passing this to a std::shared_ptr could eliminate UB.
class Foo
{
public:
virtual ~Foo() = default;
void whatever() {
if (ptr)
ptr->whateverHandler();
}
void reset() {
ptr.reset();
}
void resetBar() {
ptr.reset(new Bar);
}
// Other resets here...
private:
// Every child class should override this
virtual void whateverHandler() = 0;
std::shared_ptr<Foo> ptr;
};
class Bar : public Foo
{
public:
void whateverHandler() {
printf("Bar's handler!!! \n");
}
};
int main()
{
{
Foo f;
f.resetBar();
f.whatever();
f.resetSthElse();
f.whatever();
}
}
And IMO, having a member of type std::shared_ptr pointing to derived class is confusing; separating it might be better. And then, I think it might be the bridge design partern.
class Foo
{
public:
void whatever() {
if (ptr)
ptr->whateverHandler();
}
void reset() {
ptr.reset();
}
void resetBar() {
ptr.reset(new BarHandler);
}
// Other resets here...
private:
std::shared_ptr<FooHandler> ptr;
};
class FooHandler
{
public:
virtual ~FooHandler() = default;
// Every child class should override this
virtual void whateverHandler() = 0;
};
class BarHandler : public FooHandler
{
public:
void whateverHandler() {
printf("Bar's handler!!! \n");
}
};
int main()
{
{
Foo f;
f.resetBar();
f.whatever();
f.resetSthElse();
f.whatever();
}
}

Answer 2

The Foo::ptr holds a pointer to its mother Foo(this) with reference count 1.
In Foo::resetBar(), when Foo asking Foo::ptr to call reset(new Bar), Foo::ptr gave up its ownership to its mother Foo(this) and found out the reference count was already decreased to 0, so it need to kill Foo.
When the Foo is dead, its children are killed. So Foo::ptr must be dead, too. Then assigning the new Bar to dead Foo::ptr causes UB.