Информация об изменениях

Сообщение Re[2]: Аргументы против vector<unique_ptr<T>> от 25.01.2017 3:04

Изменено 25.01.2017 3:56 Артём

Re[2]: Аргументы против vector<unique_ptr<T>>
Здравствуйте, Vamp, Вы писали:

MB>>Кто прав?

V>Для начала надо разобраться нужен ли там пойнтер вообще. Ссылка на Жаву пугает. Если нужен — то конечно unique_ptr. Shared ptr судя по условию задачи не нужен.

Нужно изобразить иерархию с базовым типом для демонстрации некоего паттерна проектирования. Коллекция элементов базового типа, по ней перебор. Жаву не надо бояться, она не кусается- каждому овощу своё место на грядке.
Re[2]: Аргументы против vector<unique_ptr<T>>
Здравствуйте, Vamp, Вы писали:

MB>>Кто прав?

V>Для начала надо разобраться нужен ли там пойнтер вообще. Ссылка на Жаву пугает. Если нужен — то конечно unique_ptr. Shared ptr судя по условию задачи не нужен.

Нужно изобразить иерархию с базовым типом для демонстрации некоего паттерна проектирования. Коллекция элементов базового типа, по ней перебор. Жаву не надо бояться, она не кусается- каждому овощу своё место на грядке.

UPD Обсудили с коллегой дальше, после моих размышлений насчёт deleter-а и внешнего аллокатора. Сошлись, что use-case для shared_ptr такой:
динамическая библиотека (API) возвращает какой-то объект (factory method), завёрнутый в shared_ptr. Этот первый shared_ptr захватывает delete-р с аллокатором, который выделил память под этот объект. Дальше через копирующий конструктор, счётчик и delete-р копируются в shared_ptr вызывающего кода. И дальше уже без вариантов, можно хранить только в коллекции из shared_ptr.