Сообщение Re[3]: Скрыть дебри с линковкой от 03.11.2015 11:18
Изменено 03.11.2015 11:29 watchmaker
Здравствуйте, Tasheehoo, Вы писали:
T>1)Какой смысл использовать unique_ptr для pimpl? Только чтоб не звать в деструкторе delete?
Ты так говоришь, как будто это сама по себе не достаточная причина.
T>2)Зачем тут писать default?
EP>>Widget::~Widget() = default;
Чтобы unique_ptr<T> смог разрушить объект T должен быть complete типом. Если не написать явно деструктор, то компилятор сгенерирует свой автоматически, но в нём тип T будет incomplete (очевидно, что из заголовочного файла не видно внутренностей implementation, и implementation таким образом не будет полностью определённым).
Существенно тут то, что декструктор реализован в точке в которой известны внутренности implementation.
Или вопрос в том, почему написано Widget::~Widget() = default; вместо Widget::~Widget() {} ? Ну это просто такой способ чуть яснее показать семантику, что тут важно именно место реализации, а сам деструктор подойдёт и созданных компилятором (по аналогии с default реализациями операций перемещения или копирования).
T>1)Какой смысл использовать unique_ptr для pimpl? Только чтоб не звать в деструкторе delete?
Ты так говоришь, как будто это сама по себе не достаточная причина.
T>2)Зачем тут писать default?
EP>>Widget::~Widget() = default;
Чтобы unique_ptr<T> смог разрушить объект T должен быть complete типом. Если не написать явно деструктор, то компилятор сгенерирует свой автоматически, но в нём тип T будет incomplete (очевидно, что из заголовочного файла не видно внутренностей implementation, и implementation таким образом не будет полностью определённым).
Существенно тут то, что декструктор реализован в точке в которой известны внутренности implementation.
Или вопрос в том, почему написано Widget::~Widget() = default; вместо Widget::~Widget() {} ? Ну это просто такой способ чуть яснее показать семантику, что тут важно именно место реализации, а сам деструктор подойдёт и созданных компилятором (по аналогии с default реализациями операций перемещения или копирования).
Здравствуйте, Tasheehoo, Вы писали:
T>1)Какой смысл использовать unique_ptr для pimpl? Только чтоб не звать в деструкторе delete?
Ты так говоришь, как будто это сама по себе не достаточная причина.
T>2)Зачем тут писать default?
EP>>Widget::~Widget() = default;
Чтобы unique_ptr<T> смог разрушить объект, T должен быть complete типом. Если не написать явно деструктор, то компилятор сгенерирует свой автоматически, но в нём тип T будет incomplete (очевидно, что из заголовочного файла не видно внутренностей implementation, и implementation таким образом не будет полностью определённым).
Существенно, тут главное то, что декструктор реализован в точке в которой известны внутренности implementation.
Или вопрос в том, почему написано Widget::~Widget() = default; вместо Widget::~Widget() {} ? Ну это просто такой способ чуть яснее показать семантику, что тут важно именно место реализации, а сам деструктор подойдёт и созданных компилятором (по аналогии с default реализациями операций перемещения или копирования).
T>1)Какой смысл использовать unique_ptr для pimpl? Только чтоб не звать в деструкторе delete?
Ты так говоришь, как будто это сама по себе не достаточная причина.
T>2)Зачем тут писать default?
EP>>Widget::~Widget() = default;
Чтобы unique_ptr<T> смог разрушить объект, T должен быть complete типом. Если не написать явно деструктор, то компилятор сгенерирует свой автоматически, но в нём тип T будет incomplete (очевидно, что из заголовочного файла не видно внутренностей implementation, и implementation таким образом не будет полностью определённым).
Существенно, тут главное то, что декструктор реализован в точке в которой известны внутренности implementation.
Или вопрос в том, почему написано Widget::~Widget() = default; вместо Widget::~Widget() {} ? Ну это просто такой способ чуть яснее показать семантику, что тут важно именно место реализации, а сам деструктор подойдёт и созданных компилятором (по аналогии с default реализациями операций перемещения или копирования).