Чи потрібно std :: unique_ptr <T>, щоб знати повне визначення T?

Я маю код у заголовку, який виглядає приблизно так:

#include <memory>

class Thing;

class MyClass
{
    std::unique_ptr< Thing > my_thing;
};

Якщо я включаю цей заголовок у cpp, який не включає Thingвизначення типу, то це не компілюється під VS2010-SP1:

1> C: \ програмні файли (x86) \ Microsoft Visual Studio 10.0 \ VC \ include \ memory (2067): помилка C2027: використання невизначеного типу 'Thing'

Замінити std::unique_ptrна, std::shared_ptrі він компілює.

Отже, я здогадуюсь, що саме поточна реалізація VS2010 std::unique_ptrвимагає повного визначення, і це повністю залежить від впровадження.

Або це? Чи є в його стандартних вимогах щось, що унеможливлює std::unique_ptrреалізацію російською мовою роботи лише з прямою декларацією? Це дивно, оскільки він повинен містити лише покажчик Thing, чи не так?

Прийнятий звідси .

Більшість шаблонів у стандартній бібліотеці 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деструктор 's є частиною його типу, і це необхідно знати під час компіляції.

Схоже, що поточні відповіді не точно прибивають, чому конструктор (або деструктор) за замовчуванням є проблемою, але порожні, оголошені в cpp, не є.

Ось що відбувається:

Якщо зовнішній клас (тобто MyClass) не має конструктора чи деструктора, тоді компілятор генерує типові. Проблема в тому, що компілятор по суті вставляє порожній конструктор / деструктор за замовчуванням у файл .hpp. Це означає, що код за замовчуванням кондуктора / деструктора збирається разом із двійковим файлом виконавчого файлу хоста, а не бінарними файлами вашої бібліотеки. Однак це визначення насправді не може побудувати часткові класи. Отже, коли лінкер переходить у бінарний файл вашої бібліотеки і намагається отримати конструктор / деструктор, він не знаходить жодного, і ви отримуєте помилку. Якщо код конструктора / деструктора був у вашому .cpp, то у вашій бінарній бібліотеці є доступна для посилання.

Це не має нічого спільного з використанням унікального_ptr або shared_ptr, а інші відповіді, мабуть, можуть заплутати помилку в старому VC ++ для реалізації unique_ptr (VC ++ 2015 добре працює на моїй машині).

Тож мораль історії полягає в тому, що ваш заголовок повинен залишатися вільним від будь-якого визначення конструктора / деструктора. Він може містити лише їх декларацію. Наприклад, ~MyClass()=default;в hpp не працюватиме. Якщо ви дозволите компілятору вставити конструктор або деструктор за замовчуванням, ви отримаєте помилку лінкера.

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

Просто для повноти:

Заголовок: Ага

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. І це має сенс при розгляді що у випадку винятку в конструкторі унікальний_ptr знову знищується.)

Повне визначення речі потрібно в точці опису шаблону. Це точна причина, через яку ідіома складається з pimpl.

Якщо це не вдалося, люди не будуть задавати питання , як це .

Проста відповідь - просто використовувати shared_ptr замість цього.

Як на мене,

QList<QSharedPointer<ControllerBase>> controllers;

Просто включіть заголовок ...

#include <QSharedPointer>