How to avoid shared_ptr overhead when doing PIMPL

Question

AFAIK unique_ptr is quite tricky to use with PIMPL, since deleter is part of unique_ptr type so it will not work with incomplete types. On the other hand shared_ptr uses dynamic deleter so it works with incomplete types.

shared_ptr has the performance issue of giving me an atomic operations no matter if I need it or not.

Are there any other faster alternatives in std:: I can use? I am obviously fine with type erasure, I am talking about cost of atomic refcount.

#include <any>
#include <memory>
#include <iosfwd>

std::shared_ptr<std::fstream> sp;
// unique_ptr requires complete type
// std::unique_ptr<std::fstream> up;
std::any a;

#include <fstream>
int main() {
    // any requires copy_constructible
    // a = std::fstream{};  
    sp = std::make_shared<std::fstream>();
} 

notes:

• I considered any, but it does not work for some types.
• I considered unique_ptr with dynamic deleter, but AFAIK unique_ptr constructor will never "tell" the deleter what is the constructed object(to give a way to deleter to learn how to destroy the object).

P.S. I know long time ago boost::shared_ptr had macro to disable atomic refcount, but even if that is still supported I do not want to switch to boost::shared_ptr.

Answer 1

First, do note that the "atomic reference count" of shared_ptr is only a problem when you actually use it. Since your class is non-copyable (which makes sense for an interface type, and since you were willing to use unique_ptr, it must be non-copyable), the count will only ever be modified on construction and destruction. So... you shouldn't care; even if an atomic reference count was actually a big deal performance-wise, it will be a rounding error next to the cost of the memory allocation/de-allocation that accompanies it.

As to your actual problem, the only reason you're getting a compile error here is because you forced the compiler to instantiate unique_ptr<T>'s destructor from a place where T is still incomplete.

In an actual use of PIMPL, you would have a header file defining the public interface and declaring the private implementation, and also one or more .cpp files providing the implementation of these. unique_ptr<T> can work in those situations so long as the public interface type's destructor is not defined in the header:

///Interface.h
class Impl;

class Interface
{
private:
  unique_ptr<Impl> impl_;

public:
  ~Interface(); //Declaration only; prevent compiler-definition in header
};

///Interface.cpp
class Impl {...};

Interface::~Interface() = default;

This prevents the people including the header from instantiating unique_ptr<Impl>'s destructor.