Информация об изменениях

Сообщение Re[14]: Есть ли жизнь после перемещения? от 22.11.2018 8:55

Изменено 22.11.2018 9:11 rg45

Re[14]: Есть ли жизнь после перемещения?
Здравствуйте, Erop, Вы писали:

E>Что касается критики идеи с методом move у вектора, то код
std::vector<T> dst;
E>src.move_to( dst )
ничем особо не хуже метода
std::vector<T> dst = std::move( src );
кроме того, что первое сразу понятно, а второе надо знать пр std::move, конструкторы перемещения и т. д...


Вероятно, у нас разные критерии оценки. По-моему, этот код СИЛЬНО хуже:

1) Обязывает предоставлять дефолтный конструктор, что не всегда приемлемо;
2) Вводит необоснованные ограничения на использование ссылок и констант в качестве членов классов;
3) Содержит оверхед на создание никому ненужного состояния объекта;
4) Реализуется с использованием функции-члена, что противоречит принципам обобщенного программированя;
5) Резервирует имя функции-члена, создвавая предпосылки для конфликтов имен;
6) Не подходит для автоматической генерации компилятором (пониммаю, что для тебя это плюс, но не разделяю твою точку зрения);
7) Вынуждает заводить лишние локальные переменные, что крайне плохо сказывается на структуре кода.
Re[14]: Есть ли жизнь после перемещения?
Здравствуйте, Erop, Вы писали:

E>Что касается критики идеи с методом move у вектора, то код
std::vector<T> dst;
E>src.move_to( dst )
ничем особо не хуже метода
std::vector<T> dst = std::move( src );
кроме того, что первое сразу понятно, а второе надо знать пр std::move, конструкторы перемещения и т. д...


Вероятно, у нас разные критерии оценки. По-моему, этот код СИЛЬНО хуже:

1) Обязывает предоставлять дефолтный конструктор, что не всегда приемлемо;
2) Вводит необоснованные ограничения на использование ссылок и констант в качестве членов классов;
3) Содержит оверхед на создание никому ненужного состояния объекта;
4) Реализуется с использованием функции-члена, что противоречит принципам обобщенного программированя;
5) Резервирует имя функции-члена, создвавая предпосылки для конфликтов имен;
6) Плохо подходит для работы с разными типами данных. Как только src и dst станут иметь разные тут же выяснится, что в каких-то случаях удобнее иметь "move_to", а каких-то "move_from";
7) Не подходит для автоматической генерации компилятором. Пониммаю, что для тебя это плюс, но не разделяю твою точку зрения. Потому, что сейчас поддержка move семантики в большинстве случаев либо генерируется автоматически, либо сводится к тривиальному разрешить/запретить. В твоем же варианте реально нужно будет все это писать. Раздувая объем кода и натягивая массу ошибок;
8) Вынуждает заводить лишние локальные переменные, что крайне плохо сказывается на структуре кода.