Здравствуйте, B0FEE664, Вы писали:
BFE>Т.е. я ожидаю, что следующие постусловие метода set_foos(std::vector<Foo>&&) будет соблюдатся: BFE>
BFE>assert(0 == foos.capacity());
BFE>
Почему? Разве есть такие гарантии?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Почему?
Такое поведение мне кажется естественным.
Если я вижу, например, код: MyStr("5") + MyStr("6"), то результатом я ожидаю MyStr("56"), а не MyStr("11").
Так же и тут: зачем перемещённому объекту память?
E>Разве есть такие гарантии?
Нет.
Здравствуйте, B0FEE664, Вы писали:
BFE>Так же и тут: зачем перемещённому объекту память?
Ну, например, что бы не иметь выделенное "пустое" состояние...
Я согласен с тезисом, что принципу наименьшего удивление в случае обсуждаемого метода будет соответствовать поведение максимально похожее на поведение присваивания...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Такое поведение мне кажется естественным. BFE>Так же и тут: зачем перемещённому объекту память?
Незачем. Но дело ведь не в этом, а в том, что и причин для её отсутствия нет.
Смысл в следующем: только вызывающая сторона знает нужен ли ей вектор foos после вызова cur_bar.set_foos или нет.
И тогда два варианта использования:
cur_bar.set_foos(foos); // Вариант 1. Данные foos еще понадобятся. Копирование в аргумент, перемещение внутри функции.
cur_bar.set_foos(std::move(foos)); // Вариант 2. Данные foos больше не нужны . Перемещение в аргумент, перемещение внутри функции.
Еще бонус в том, что не нужно удваивать интерфейс struct Bar, чтобы поддерживать и копирование и перемещение.