Сообщение 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 судя по условию задачи не нужен.
Нужно изобразить иерархию с базовым типом для демонстрации некоего паттерна проектирования. Коллекция элементов базового типа, по ней перебор. Жаву не надо бояться, она не кусается- каждому овощу своё место на грядке.
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.
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.