Forward declaration with reference-counting smart pointer - c++

Question

I have implemented a class reference<T> that keeps track of the amount of references to a T which derives from reference_countable.
I have a problem with it with respect to forward declaring the T of the reference<T>, similar to that of std::unique_ptr<T>. With std::unique_ptr<T> the issue comes from the destructor not beeing known, so all you have to do is put the destructor of your class into the cpp file, like so:
header:
class MyClass;
class A
{
std::unique_ptr<MyClass> my_class;
}
implementation:
A:~A() = default;
However, in my version, where std::unique_ptr<MyClass> is replaced by reference<MyClass>, the reference_countable must also be decremented and incremented. Which requires me to also put the copy-assignment and copy-constructor of A in cpp file when MyClass is only forward declared.
Is there a way to avoid having to put the implementation for these three functions in the cpp file for all classes with a reference<T> member?
I've tried to describe it as simple as I can, but for more detail, here is a simple version of the problem. Specifically, the need to define the copy-constructor of A in a.cpp.
my_class.h
#pragma once
#include "minimal_ref_counter.h"
class MyClass : public minimal_reference_countable
{
};
a.h
#pragma once
#include "minimal_ref_counter.h"
class MyClass;
class A
{
public:
A();
~A();
A(const A&);
minimal_reference_counter<MyClass> my_class;
};
a.cpp
#include "test.h"
#include "myclass.h"
A::A()
: my_class(new MyClass())
{}
A::~A() = default;
A::A(const A&) = default;
some_other_code.cpp
#include "a.h"
void some_function()
{
A a1;
A a2 = a1; // this code does not compile without the copy assignment operator beeing implemented externally.
}
minimal_ref_counter.h
#pragma once
#include <atomic>
class minimal_reference_countable
{
template<typename T>
friend class minimal_reference_counter;
std::atomic_int m_references = 0;
auto reference_count() const { return m_references.load(); }
void decrement() { --m_references; }
void increment() { ++m_references; }
};
template<typename T>
class minimal_reference_counter
{
public:
minimal_reference_counter(T* t = nullptr)
{
assign(t);
}
~minimal_reference_counter()
{
reset();
}
minimal_reference_counter(const minimal_reference_counter& r)
{
*this = r;
}
minimal_reference_counter(minimal_reference_counter&& r)
{
*this = std::move(r);
}
minimal_reference_counter& operator=(const minimal_reference_counter& r)
{
assign(r.m_ptr);
return *this;
}
minimal_reference_counter& operator=(minimal_reference_counter&& r)
{
assign(r.m_ptr);
r.reset();
return *this;
}
void reset()
{
if (!m_ptr) return;
m_ptr->decrement();
if (m_ptr->reference_count() == 0)
{
delete m_ptr;
}
m_ptr = nullptr;
}
private:
void assign(T* ptr)
{
reset();
m_ptr = ptr;
if (m_ptr) m_ptr->increment();
}
T* m_ptr = nullptr;
};

Answer 1

C++ templates are lazy. Instantiations are deferred until necessary. The reason to put the destructor in the cpp file when you have a member std::unique_ptr of an incomplete type, later completed, is that the destructor needs the destructor of unique_ptr, thus instantiating it, which needs the destructor of the pointed-to type which requires that type to be complete. This chain of dependencies triggered by the definition of the destructor must be deferred until such time as the pointed-to type is complete.
In your reference counted pointer case, you wonder if the copy constructor, copy assignment operator, and destructor of the pointer necessarily require completeness of the pointed-to type, and likewise their instantiations be deferred until such time as the pointed to type is complete.
Because the pointer destructor potentially invokes the destructor of the pointed-to type, that type necessarily must be complete when the pointer destructor is instantiated. This is similar to unique_ptr and so should be unsurprising.
Similarly, the pointer copy assignment potentially invokes the destructor of the pointed-to type. It replaces the pointee with another pointee and decrements the original pointee's reference count and destroys it if necessary. So, for the same reason as the destructor, the pointer copy assignment operator requires the pointed-to type necessarily be complete when it is instantiated.
The copy constructor is more subtle. No potential destructions of the pointed-to type are invoked. However, with this implementation, we act on a base class of the pointed-to type to increment the reference count. This requires completeness, as otherwise there are no base classes. So, with this implementation, yes, the poitned-to type necessarily must be complete when the copy constructor is instantiated.
There are alternative implementations, of course. One could keep both a T* and a minimal_reference_counter<T>*, instead of finding the latter from the former as a base class. shared_ptr does this. In fact, one could also store the destructor as a function pointer and not require the other awkward instantiation deferrals. shared_ptr does this too.