Тут, вероятно, это бесполезно (если брать комплишен хендлеры в тех либах, с которыми я знаком)
соблюдение семантики, это буквально "вызывается один раз"
понел спасибо, где можно посмотреть реализацию? это тупо rvalue overload?
Какую реализацию? Потенциальную? struct x { void operator()(int) && {} };
ну типа как уничтожается функция внутри move. она же одноразовая
Если это только для перегрузки, тут пессимизация, потому что первый move это таки конструктор.
vector x () && { return std::move(field_vector); }
Ну конечно, move как cast для вызова это одно а auto x = move это создание второго объекта. Если callable например std function то это ещё и виртуальный move
что за виртуальный мув?
std::function например, это type erasure. Соответственно copy и move у него виртуальные.
Он же внутри себя содержит указатель на кучу (unique_ptr), при муве std::function мувается этот std::unique_ptr, без никаких "виртуальных мувов"
вот это больше похоже на правду, писал классы с type erasure (в т. ч. callable), ни разу виртуальное присваивание делать не приходилось
Ну обычно же все рассчитывают что там работает small object optimization, не так ли? Если функция вписывается в soo, move/copy всегда виртуальные. И что хреново, эти самые copy/move всегда генерируются и не могут быть удалены.
мув там самый обыкновенный
также можно сказать про любой нетривиальный мув, типа просто он сложнее
В std function? Обыкновенный?
да, все мув конструкторы бывают обыкновенные и тривиальные, так что этот обыкновенный
где про это почитать?
Возможно, идея - "call-once" семантика function wrapper
Ну если это просто шаблонный код можно конечно сделать call через move, но для этого не нужен move constructor. Если говорить например про std function, там вообще по барабану, она в стандарте даже не истинно const.
выше описывались причины почему может потребоваться мувать
А вообще с call-once всё сложно. Нужно учитывать что функтор может иметь доступ сам к себе если что. То есть безопасный call-once должен перед вызовом обязательно сам себя через move скопировать.
Согласен, это нормально если функтор переписывает сам себя.
ну нет, это уже проблема самого объекта, если потенциально он делает рекурсию в себя. И вообще-то вызов сколько угодно раз функции помеченной как && не является ошибкой, просто семантически это неверно
Например интегрированный в state machine callback который мы все время переписываем при переходе между состояниями. Тут как раз опасно иметь дело с reference в качестве контекса выполнения текущего callback вместо moved out state.
Обсуждают сегодня