Здравствуйте, watchmaker, Вы писали:

W>Нет, смысл этого в другом — источник должен остаться в таком состоянии, что его удаление не уронит программу. Если у тебя есть unique_ptr, то в реализации должен изменяться указатель у источника при move — иначе память, на которую будут ссылаться оба указателя, будет освобождена дважды и программа упадёт.

Это понятно.

W>Если другой wrapper_ptr не удаляет память в деструкторе, то указатель можно и не менять — всё будет работать. Если wrapper_ref содержит ссылку — то тем более её нет нужды менять — её «удаление» не уронит программу просто из-за того, что разрушение ссылки в деструкторе — суть отсутствие каких-либо действий.

А как быть в случае ссылки и movе оператора? Я же не могу переприсвоить ссылку?

W>В языке C++ есть понятие «implementation-defined behavior» — то есть в каждом конкретном случае поведение определено, но какое оно — зависит от реализации и может меняться.
W>Тут примерно то же самое — объект остался в консинстентном состоянии, но неизвестно какое это состояние. Так, например, то же перемещение из vector<T> может как сделать объект пустым, так и наполнить его какими-нибудь данными. Оба случая встречаются на практике. В обоих случаях поведение является допустимым, а состояние объекта остаётся согласованным, но вот использовать этот объект просто так не стоит — ведь записав в него через push_back какие-то данные не будет гарантии, что в нём не останется какой-то другой мусор.
W>Вот именно из-за этого и не стоит использовать объекты после move.

Т.е. у такого объекта, в случае со ссылкой, должен быть организован некий zomby mode ?

V>>У классов без ссылок я могу переинициализировать члены — я так и делаю.
W>Ясно, а зачем? Использовал обёртку и выкинул, вместо этого создал другую. Такой вариант тебе не подходит? Ну тогда используй просто указатели вместо ссылок — и вопрос решён.

Походит, но не думал что с ссылкой придется возится с тем чтобы обеспечить контроль на случай если перенесенный объект кто-то дернет случайно.

Сложность еще в том что до этого класс не имел конструктора по умолчанию и не было логики которая проверяла валидный объект или нет (кроме assert-ов).
Теперь придется везде добавлять проверки. Я правильно понимаю?

Здравствуйте, watchmaker, Вы писали:

W>Нет, смысл этого в другом — источник должен остаться в таком состоянии, что его удаление не уронит программу. Если у тебя есть unique_ptr, то в реализации должен изменяться указатель у источника при move — иначе память, на которую будут ссылаться оба указателя, будет освобождена дважды и программа упадёт.

Это понятно.

W>Если другой wrapper_ptr не удаляет память в деструкторе, то указатель можно и не менять — всё будет работать. Если wrapper_ref содержит ссылку — то тем более её нет нужды менять — её «удаление» не уронит программу просто из-за того, что разрушение ссылки в деструкторе — суть отсутствие каких-либо действий.

А как быть в случае ссылки и movе оператора? Я же не могу переприсвоить ссылку?

W>В языке C++ есть понятие «implementation-defined behavior» — то есть в каждом конкретном случае поведение определено, но какое оно — зависит от реализации и может меняться.
W>Тут примерно то же самое — объект остался в консинстентном состоянии, но неизвестно какое это состояние. Так, например, то же перемещение из vector<T> может как сделать объект пустым, так и наполнить его какими-нибудь данными. Оба случая встречаются на практике. В обоих случаях поведение является допустимым, а состояние объекта остаётся согласованным, но вот использовать этот объект просто так не стоит — ведь записав в него через push_back какие-то данные не будет гарантии, что в нём не останется какой-то другой мусор.
W>Вот именно из-за этого и не стоит использовать объекты после move.

Т.е. у такого объекта, в случае со ссылкой, должен быть организован некий zomby mode ?

V>>У классов без ссылок я могу переинициализировать члены — я так и делаю.
W>Ясно, а зачем? Использовал обёртку и выкинул, вместо этого создал другую. Такой вариант тебе не подходит? Ну тогда используй просто указатели вместо ссылок — и вопрос решён.

Подходит, но не думал что с ссылкой придется возится с тем, чтобы обеспечить контроль на случай, если перенесенный объект кто-то дернет случайно.

Сложность еще в том что до этого класс не имел конструктора по умолчанию и не было логики которая проверяла валидный объект или нет (кроме assert-ов).
Теперь придется везде добавлять проверки. Я правильно понимаю?