CD
При этом, скажем, std::swap использует весьма нетривиальное утверждение
auto a = std::move(x);
x = std::move(y); //почему эта операция корректна над объектом после перемещения?
y = std::move(x);
Size: a a a
2020 October 13
CD
B
auto a = std::move(x);
x = std::move(y); //почему эта операция корректна над объектом после перемещения?
y = std::move(x);
Почему нет?
CD
Почему нет?
а где прописанное требование к move ctor оставить объект в состоянии таком, что объект может использоваться в левой части операции присваивания?
B
а где прописанное требование к move ctor оставить объект в состоянии таком, что объект может использоваться в левой части операции присваивания?
Ну потому что в lvalue может быть что угодно в любом состоянии?
AP
а где прописанное требование к move ctor оставить объект в состоянии таком, что объект может использоваться в левой части операции присваивания?
Было для контейнеров стандартной библиотеки (что-то про валидное не неспецифицированное состояние)
CD
Ну потому что в lvalue может быть что угодно в любом состоянии?
Это вроде неверно для присваивания контейнеров с разными значениями аллокаторов
B
Это вроде неверно для присваивания контейнеров с разными значениями аллокаторов
У тебя в примере и не контейнер, а что-то абстрактное
CD
У тебя в примере и не контейнер, а что-то абстрактное
Вы указываете предикат "для любого", он опровергнут контрпримером. Неверно, что левый аргумент присваивания не важен при выполнении операции - класс может иметь неперемещаемые инварианты
ПК
Вы указываете предикат "для любого", он опровергнут контрпримером. Неверно, что левый аргумент присваивания не важен при выполнении операции - класс может иметь неперемещаемые инварианты
Это всё зависит от реализации мув операций в конкретном классе. Обычно делают как в std - valid but unspecified
CD
Было для контейнеров стандартной библиотеки (что-то про валидное не неспецифицированное состояние)
А вот требовать какое-то валидное состояние это требовать неразрушающего перемещения, это слишком жесткое требование
По факту для MoveCtor нужно прописать именно требование эквивалентности
и
По факту для MoveCtor нужно прописать именно требование эквивалентности
x = expression
и
auto y = std::move(x);
x = expression;
CD
То есть если некоторый expression может использоваться в правой части assignment, то может использоваться и при перемещении объекта
CD
То есть если некоторый expression может использоваться в правой части assignment, то может использоваться и при перемещении объекта
Это собственно эквивалентно условию возможного swap
CD
Это всё зависит от реализации мув операций в конкретном классе. Обычно делают как в std - valid but unspecified
Ты запретишь перемещение объектов, содержащих ненулевой unique_ptr, это равносильно неразрушающему перемещению, а в текущий момент стандарт и p1144 рассматривает перемещение скорее как разрушающее
m
Там базовая идея очень крутая, да. Мне кажется, что в стандарте фундаментально не хватает правил семантики операций - поправьте меня, стандарт не накладывает вообще никаких ограничений для функций, рассматриваемых компилятором как CopyCtor и MoveCtor
С сайд эффектами из-за copy elision тоже не очевидно что делать. Жестко запрещать не хочется, например, из-за юзкейса подсчета объектов определенного типа.
upd: Нужно открывать ссылки до того как коментируешь. -_-
upd: Нужно открывать ссылки до того как коментируешь. -_-
CD
Было для контейнеров стандартной библиотеки (что-то про валидное не неспецифицированное состояние)
Кстати, в стандартной библиотеке есть проблема именно из-за такого определения, у std::list не получается noexcept перемещения
CD
С сайд эффектами из-за copy elision тоже не очевидно что делать. Жестко запрещать не хочется, например, из-за юзкейса подсчета объектов определенного типа.
upd: Нужно открывать ссылки до того как коментируешь. -_-
upd: Нужно открывать ссылки до того как коментируешь. -_-
Этой проблемы нет, это еще один хитрый инвариант, связанный с перемещением. Следующий код эквивалентен:
{
::z = std::move(x);
}
и{
auto y = std::move(x);
::z = std::move(y);
}CD
даже если происходит атомарное изменение счетчика ссылок вверх-вниз с барьером, программа не должна зависеть от эффектов этого
m
даже если происходит атомарное изменение счетчика ссылок вверх-вниз с барьером, программа не должна зависеть от эффектов этого
Но для подсчета количества инстансов это будет означать что нельзя обращаться к счетчику если параллельно с этим происходит работа с подсчитываемыми объектами и они могут стать целью copy elision.