Недавно реализованные методы с семантикой перемещения сделаны с дублированием кода (пример PIVector::push_back). Более удачное решение- оставить только вариант метода с Rvalue ссылкой. Для передачи в elementNew использовать std::forward<T>(v). См. "Краткое введение в rvalue-ссылки".
Еще метод resize поддерживает только семантику копирования. А значит с помощью контейнеров невозможно работать с 'no copy' классами.
Недавно реализованные методы с семантикой перемещения сделаны с дублированием кода (пример [`PIVector::push_back`](https://git.shs.tools/SHS/pip/src/commit/70a7363f7621d78b1a970d0c53493cc32a6f3cfa/lib/main/containers/pivector.h#L335)). Более удачное решение- оставить только вариант метода с Rvalue ссылкой. Для передачи в `elementNew` использовать `std::forward<T>(v)`. См. ["Краткое введение в rvalue-ссылки"](https://habr.com/ru/post/226229/).
Еще метод `resize` поддерживает только семантику копирования. А значит с помощью контейнеров невозможно работать с 'no copy' классами.
peri4
was assigned by zzuummaa2020-08-05 12:24:56 +03:00
andrey
was assigned by zzuummaa2020-08-05 12:24:56 +03:00
С контейнерами в принципе нельзя допускать работу с ‘no copy’ классами, это ведёт к трудно отлавливаемым ошибкам, так что это только плюс, что их нельзя туда пихать.
Все ‘no copy’ классы нужно держать в контейнерах только по указателям.
С контейнерами в принципе нельзя допускать работу с ‘no copy’ классами, это ведёт к трудно отлавливаемым ошибкам, так что это только плюс, что их нельзя туда пихать.
Все ‘no copy’ классы нужно держать в контейнерах только по указателям.
Степ, для интереса попробуй выпилить из контейнеров операторы const &, а оставь только &&. И скомпиляй.
Причем, даже в std::vector есть два варианта:
void push_back(const value_type& __x)
#if __cplusplus >= 201103L
void push_back(value_type&& __x)
это тоже явно неспроста
Степ, для интереса попробуй выпилить из контейнеров операторы const &, а оставь только &&. И скомпиляй
Завтра по внимательнее гляну вывод, но мое мнение по контейнерам врядли изменится.
Там в контейнерах не совсем правильно реализованы методы с &&. Нужно в некоторых местах вместо std::move использовать std::forward. И кажется, дизайн классов не совсем готов к семантике перемещения.
Сегодня переделал PIThreadPoolExecutor и PIBlockingDequeue. На сколько я успел убедиться, классы полностью поддерживают обе семантики. По идее, код, использующий эти классы, никак не должен меняться.
> Степ, для интереса попробуй выпилить из контейнеров операторы const &, а оставь только &&. И скомпиляй
Завтра по внимательнее гляну вывод, но мое мнение по контейнерам врядли изменится.
Там в контейнерах не совсем правильно реализованы методы с &&. Нужно в некоторых местах вместо `std::move` использовать `std::forward`. И кажется, дизайн классов не совсем готов к семантике перемещения.
Сегодня переделал [PIThreadPoolExecutor](https://git.shs.tools/SHS/pip/src/commit/3cfdda7365b2b772a55ecafc89f5c1a841cd91ee/lib/main/thread/piexecutor.h) и [PIBlockingDequeue](https://git.shs.tools/SHS/pip/src/commit/3cfdda7365b2b772a55ecafc89f5c1a841cd91ee/lib/main/thread/piblockingdequeue.h). На сколько я успел убедиться, классы полностью поддерживают обе семантики. По идее, код, использующий эти классы, никак не должен меняться.
Завтра тоже гляну по внимательнее. Думаю, что они для лучшей скорости работы специализированную функцию оставили.
> Причем, даже в std::vector есть два варианта:
>
> void push_back(const value_type& __x)
> #if __cplusplus >= 201103L
> void push_back(value_type&& __x)
>
> это тоже явно неспроста
Завтра тоже гляну по внимательнее. Думаю, что они для лучшей скорости работы специализированную функцию оставили.
Вопрос на счет дублирования const & и && закрываю. Универсальные ссылки && работают только если template на уровне метода, а не на уровне класса.
Работа с no copy классами отклонена из- за несоответствия идеологии.
Вопрос на счет дублирования const & и && закрываю. Универсальные ссылки && работают только если template на уровне метода, а не на уровне класса.
Работа с no copy классами отклонена из- за несоответствия идеологии.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Недавно реализованные методы с семантикой перемещения сделаны с дублированием кода (пример
PIVector::push_back). Более удачное решение- оставить только вариант метода с Rvalue ссылкой. Для передачи вelementNewиспользоватьstd::forward<T>(v). См. "Краткое введение в rvalue-ссылки".Еще метод
resizeподдерживает только семантику копирования. А значит с помощью контейнеров невозможно работать с 'no copy' классами.С контейнерами в принципе нельзя допускать работу с ‘no copy’ классами, это ведёт к трудно отлавливаемым ошибкам, так что это только плюс, что их нельзя туда пихать.
Все ‘no copy’ классы нужно держать в контейнерах только по указателям.
Степ, для интереса попробуй выпилить из контейнеров операторы const &, а оставь только &&. И скомпиляй.
Причем, даже в std::vector есть два варианта:
void push_back(const value_type& __x)
#if __cplusplus >= 201103L
void push_back(value_type&& __x)
это тоже явно неспроста
Завтра по внимательнее гляну вывод, но мое мнение по контейнерам врядли изменится.
Там в контейнерах не совсем правильно реализованы методы с &&. Нужно в некоторых местах вместо
std::moveиспользоватьstd::forward. И кажется, дизайн классов не совсем готов к семантике перемещения.Сегодня переделал PIThreadPoolExecutor и PIBlockingDequeue. На сколько я успел убедиться, классы полностью поддерживают обе семантики. По идее, код, использующий эти классы, никак не должен меняться.
Завтра тоже гляну по внимательнее. Думаю, что они для лучшей скорости работы специализированную функцию оставили.
Вопрос на счет дублирования const & и && закрываю. Универсальные ссылки && работают только если template на уровне метода, а не на уровне класса.
Работа с no copy классами отклонена из- за несоответствия идеологии.