Требуется ли std :: unique_ptr ‹T›, чтобы знать полное определение T?

Взято из здесь.

Большинство шаблонов в стандартной библиотеке C ++ требуют, чтобы они создавались с полными типами. Однако shared_ptr и unique_ptr являются частичными исключениями. Некоторые, но не все их члены могут быть созданы с неполными типами. Мотивация для этого - поддержка таких идиом, как pimpl с использованием интеллектуальных указателей, и без риска неопределенного поведения.

Неопределенное поведение может возникнуть, если у вас есть неполный тип и вы вызываете для него delete:

class A;
A* a = ...;
delete a;

Выше приведен правовой кодекс. Он будет компилироваться. Ваш компилятор может выдавать или не выдавать предупреждение для вышеуказанного кода, подобного приведенному выше. Когда он выполнится, вероятно, случатся плохие вещи. Если вам очень повезет, ваша программа выйдет из строя. Однако более вероятным исходом является то, что ваша программа будет молча утечь память, поскольку ~A() не будет вызываться.

Использование auto_ptr<A> в приведенном выше примере не помогает. Вы по-прежнему получаете такое же неопределенное поведение, как если бы вы использовали необработанный указатель.

Тем не менее, использование неполных занятий в определенных местах очень полезно! Здесь помогают shared_ptr и unique_ptr. Использование одного из этих интеллектуальных указателей позволит вам избежать неполного типа, за исключением случаев, когда необходимо иметь полный тип. И, что наиболее важно, когда необходимо иметь полный тип, вы получите ошибку времени компиляции, если попытаетесь использовать интеллектуальный указатель с неполным типом в этот момент.

Больше никакого неопределенного поведения:

Если ваш код компилируется, значит, вы использовали полный тип везде, где вам нужно.

class A
{
    class impl;
    std::unique_ptr<impl> ptr_;  // ok!

public:
    A();
    ~A();
    // ...
};

shared_ptr и unique_ptr требуют полного типа в разных местах. Причины неясны, они связаны с динамическим удалением по сравнению со статическим. Точные причины не важны. Фактически, в большинстве случаев для вас не очень важно знать, где именно требуется полный тип. Просто напишите код, и если вы ошибетесь, компилятор вам скажет.

Однако на случай, если это будет полезно для вас, вот таблица, которая документирует несколько членов shared_ptr и unique_ptr в отношении требований полноты. Если член требует полного типа, тогда запись имеет "C", в противном случае запись таблицы заполняется "I".

Complete type requirements for unique_ptr and shared_ptr

                            unique_ptr       shared_ptr
+------------------------+---------------+---------------+
|          P()           |      I        |      I        |
|  default constructor   |               |               |
+------------------------+---------------+---------------+
|      P(const P&)       |     N/A       |      I        |
|    copy constructor    |               |               |
+------------------------+---------------+---------------+
|         P(P&&)         |      I        |      I        |
|    move constructor    |               |               |
+------------------------+---------------+---------------+
|         ~P()           |      C        |      I        |
|       destructor       |               |               |
+------------------------+---------------+---------------+
|         P(A*)          |      I        |      C        |
+------------------------+---------------+---------------+
|  operator=(const P&)   |     N/A       |      I        |
|    copy assignment     |               |               |
+------------------------+---------------+---------------+
|    operator=(P&&)      |      C        |      I        |
|    move assignment     |               |               |
+------------------------+---------------+---------------+
|        reset()         |      C        |      I        |
+------------------------+---------------+---------------+
|       reset(A*)        |      C        |      C        |
+------------------------+---------------+---------------+

Любые операции, требующие преобразования указателей, требуют полных типов как для unique_ptr, так и для shared_ptr.

Конструктор unique_ptr<A>{A*} может обойтись неполным A только в том случае, если компилятору не требуется настраивать вызов ~unique_ptr<A>(). Например, если вы поместите unique_ptr в кучу, вы можете обойтись неполным A. Более подробную информацию по этому поводу можно найти в ответе BarryTheHatchet здесь.

Компилятору необходимо определение Thing для создания деструктора по умолчанию для MyClass. Если вы явно объявляете деструктор и перемещаете его (пустую) реализацию в файл CPP, код должен компилироваться.

Это не зависит от реализации. Причина, по которой это работает, заключается в том, что shared_ptr определяет правильный деструктор для вызова во время выполнения - он не является частью сигнатуры типа. Однако деструктор unique_ptr является частью его типа, и он должен быть известен во время компиляции.

Похоже, что текущие ответы не совсем точно объясняют, почему конструктор (или деструктор) по умолчанию является проблемой, а пустые, объявленные в cpp, нет.

Вот что происходит:

Если внешний класс (например, MyClass) не имеет конструктора или деструктора, компилятор генерирует их по умолчанию. Проблема в том, что компилятор по существу вставляет пустой конструктор / деструктор по умолчанию в файл .hpp. Это означает, что код для конструктора / деструктора по умолчанию компилируется вместе с двоичным файлом исполняемого файла хоста, а не вместе с двоичными файлами вашей библиотеки. Однако эти определения не могут построить частичные классы. Поэтому, когда компоновщик входит в двоичный файл вашей библиотеки и пытается получить конструктор / деструктор, он ничего не находит, и вы получаете ошибку. Если код конструктора / деструктора был в вашем .cpp, значит, у вашей библиотеки есть его для связывания.

Это не имеет ничего общего с использованием unique_ptr или shared_ptr, и другие ответы кажутся возможной сбивающей с толку ошибкой в ​​старом VC ++ для реализации unique_ptr (VC ++ 2015 отлично работает на моей машине).

Итак, мораль этой истории заключается в том, что ваш заголовок не должен содержать каких-либо определений конструктора / деструктора. Он может содержать только их декларацию. Например, ~MyClass()=default; в hpp работать не будет. Если вы разрешите компилятору вставлять конструктор или деструктор по умолчанию, вы получите ошибку компоновщика.

Еще одно замечание: если вы все еще получаете эту ошибку даже после того, как у вас есть конструктор и деструктор в файле cpp, то, скорее всего, причина в том, что ваша библиотека не компилируется должным образом. Например, однажды я просто изменил тип проекта с консоли на библиотеку в VC ++, и я получил эту ошибку, потому что VC ++ не добавил символ препроцессора _LIB, и это привело к тому же самому сообщению об ошибке.

Просто для полноты:

Заголовок: A.h

class B; // forward declaration

class A
{
    std::unique_ptr<B> ptr_;  // ok!  
public:
    A();
    ~A();
    // ...
};

Источник A.cpp:

class B {  ...  }; // class definition

A::A() { ... }
A::~A() { ... }

Определение класса B должно просматриваться конструктором, деструктором и всем, что может косвенно удалить B. (Хотя конструктор не фигурирует в приведенном выше списке, в VS2017 даже конструктору требуется определение B. И это имеет смысл при рассмотрении что в случае исключения в конструкторе unique_ptr снова уничтожается.)

Полное определение Вещи требуется в момент создания экземпляра шаблона. Это точная причина компиляции идиомы pimpl.

Если бы это было невозможно, люди не задавали бы вопросов вроде this.

Я искал способ использовать идиому PIMPL с std::unique_ptr. Это руководство - отличный ресурс.

Вкратце, вот что вы можете сделать, чтобы это работало:

my_class.h

#include <memory>

class Thing;

class MyClass
{
    ~MyClass(); // <--- Added
    std::unique_ptr< Thing > my_thing;
};

my_class.cpp

MyClass::~MyClass() = default; // Or a custom implementation

Простой ответ - просто используйте вместо этого shared_ptr.

Что касается меня,

QList<QSharedPointer<ControllerBase>> controllers;

Просто включите заголовок ...

#include <QSharedPointer>