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

Сообщение Re[5]: Какой контейнер из стандартных оптимальнее всего испо от 02.01.2024 13:33

Изменено 02.01.2024 13:39 rg45

Re[5]: Какой контейнер из стандартных оптимальнее всего испо
Здравствуйте, Marty, Вы писали:

M>А можно раскрыть мысль? Какие проблемы с объектами в очереди? И как оно влияет на тип очереди, который лучше использовать?


Ну допустим, у нас очередь из std::unique_ptr (ну или какого-то типа, подобного unique_ptr). Что происходит с объектом умного указателя при извлечении из очереди? Просто передвинуть индекс не вариант, наверное, нужно же завершить время жизни и самого указателя, и объекта, на который он указывает, так ведь? А потом, когда до этого элемента снова по кругу дойдет очередь, создать на его месте новый объект умного указателя. Наверное, самое простое, что можно придумать — это оборачивать все элементы очереди в std::optional — чтоб не глотать пыль с буферами и с placement new/delete. Такой вариант будет универсальным, но как он повлияет на производительность очередей простых типов? Можно вместо std::optional использовать шаблонную обертку со специализациями, которая для сложных типов будет использовать std::optional, а для простых не будет делать ничего (вырожденная пустышка). Но ведь это же нужно еще делать, это не в одну строчку решение.
Re[5]: Какой контейнер из стандартных оптимальнее всего испо
Здравствуйте, Marty, Вы писали:

M>А можно раскрыть мысль? Какие проблемы с объектами в очереди? И как оно влияет на тип очереди, который лучше использовать?


Ну допустим, у нас очередь объектов с нетривиальным конструированием и разрушением. Что происходит когда мы извлекаем объект такого типа из очереди? Просто передвинуть индекс не вариант, наверное, нужно же еще и корректно завершить время жизни объекта, так ведь? А потом, когда до этого элемента снова по кругу дойдет очередь, создать на его месте новый объект. Наверное, самое простое, что можно придумать — это оборачивать все элементы очереди в std::optional — чтоб не глотать пыль с буферами и с placement new/delete. Такой вариант будет универсальным как для простых, так и для сложных типов. Но как такая реализация повлияет на производительность очередей простых типов? Можно вместо std::optional использовать шаблонную обертку со специализациями, которая для сложных типов будет использовать std::optional, а для простых не будет делать ничего (вырожденная пустышка). Но ведь это же нужно еще делать, это не в одну строчку решение.