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

VT>Кстати, если одиночный вызов функции "std::move(smth)" смысла не имеет, то может нужно, чтобы её в стандарте пометили как nodiscard?

Я всегда придерживался и придерживаюсь мнения, что вещи лучше называть своими именами, а функциям давать названия, соответствующие производимому ими эффекту. Исходя из этого, move — не очень удачный выбор, ИМХО.

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

R> Я всегда придерживался и придерживаюсь мнения, что вещи лучше называть своими именами, а функциям давать названия, соответствующие производимому ими эффекту.

Я согласен с таким подходом и тоже стараюсь его придерживаться. Собственно, исходя из конечного эффекта, который функция move производит в выражении, в котором она употребляется, я и считаю её название подходящим (тоже ИМХО) .

В выражении b = a выполняется копирование, в выражении b = std::move(a) происходит перемещение внутренностей из a в b, в этом смысл действия, а не в преобразовании типов. Технически да, с одной стороны (b) принимается параметр в виде rvalue-ссылки, с другой (a) — преобразование в rvalue-ссылку, чтобы "совместилось" с нужным конструктором/оператором/методом. Но далее фактически выполняется перемещение. А rvalue-ссылки — это всего лишь механизм/реализация, существующие на текущий момент (до C++11 их не было, есть гарантии, что в С++32 не появятся другие?). Конструкторы же тоже называют copy/move constructors, а не lvalue/rvalue constructors, т.е. по смыслу операции, а не по фактическим параметрам. Ну и, в конечном итоге, лично мне приятнее и понятнее в программе видеть b = std::move(a), а не b = rvalue_cast(a). Но это уже дело вкуса.

Вот такое у меня оправдание названия для move .

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

VT>Все темы может и не закроет, но в документе по ссылке ситуации с условиями вполне разбираются.

Видел. Не очень-то с ними разбираются. Просто действуют, предполагая, что худший сценарий возможен, выдавая диагностику, если указатель провис в хотя бы одной из веток условия. Для вызова методов возможно перемещенного объекта по логике то же самое наверное предлагается.

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


VT>Я согласен с таким подходом и тоже стараюсь его придерживаться. Собственно, исходя из конечного эффекта, который функция move производит в выражении, в котором она употребляется, я и считаю её название подходящим (тоже ИМХО) .

вот что дедушка пишет по этому поводу

move(x) means 'give me an rvalue reference to x.' That is, std::move(x) does not move anything; instead, it allows a user to move x. It would have been better if move() had been called rval(), but the name move() has been used for this operation for years

и я с ним полностью согласен. move ничего не мувает, а всего лишь кастит к rvalue-ссылке, поэтому название у функции не совсем корректно.

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

E>>Ну если всё равно копию возвращать, то всё понятно, а число случаев, когда понадобится move в этом сценарии будет довольно маленьким...

V>Согласен, но случаи все-таки есть.
Ну так нужен анализ их важности.
При этом RVO всё равно остался самым логичным механизмом на эту тему, так как фактически RVO -- это синтаксический сахар вокруг возврата результата через параметр.
Так что и дальше можно обсуждать механизмы по управлению RVO...

V>Но это не специфика move-конструктора. C copy-конструктором все тоже самое. В С++ нужно смотреть подходит ли вам дефолтная реализация. Просто возьмите за правило: если вам не подходит дефолтный copy-конструктор,

Конструктор копии был всегда, в отличии от. То, как сделали move-семантику, неизбежно приводит к тому, что она тихо и автоматически расползается по коду. Я считаю это одним из недостатков, а ты?

V> и move-конструктор не подойдет, его нужно переопределить.
Даже это утверждение неверное, к сожалению. Я знаю примеры, когда дефолтный конструктор копии работает корректно, а дефолтный конструктор перемещения -- нет. Причём молча с очень отдалёнными последствиями.

V>Но это все только в том случае, если вы решите осознанно использовать move. Если вы его явно не определите, тое компилятор сам запретит его использование, за вас и старый код не поломается.
Если библиотечные базы его начнут использовать, то всё не так радужно

E>>Если она так идеально работает, то почему бы не сделать её работу обязательной и контролируемой?

V>В С++ и так много чего нужно контролировать, зачем вам еще одна головная боль там, где и так все хорошо .
Ну обычно оптимизация нужна в некоторых относительно редких местах, именно в них при случае контроль мог бы пригодиться. В остальных можно не делать ничего. Это, кстати, тоже не соответствует тому, как ввели move-семантику


V>Я не спорю что есть проблемы, но, на мой взгляд, текущая реализация лучше продумана и создает меньше проблем и вопросов, чем предлагаемое вами решение.
Я не предлагаю решение, я просто показываю, что то как сделали является вовсе не единственной альтернативой. На моё взгляд главная проблема, которую чинил move-конструктор -- это кривой дизайн std::vector со товарищи...
При этом его так и не выпрямили


V>По умолчанию, сама она к вам не придет. Для этого, как минимум, нужно начать определять свои move-конструкторы. Я уже написал выше почему.

Это так в маленьких, свеженьких, компактных сфероконновакуумных проектах так. Если речь о чём-то вроде MSWord, например, или ещё более развесистом и старом проекте, то там нет выбора включать или нет. Либо на уровне проекта новшество просто запрещается полностью, либо оно так устроено, что оно не умеет саморасползаться, как, например, auto или лямбды, либо оно расползается по везде, просто как раковые метастазы. В этом смысле move-семантика примерно на грани онкологии...

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

R>Есть старый и мы хотим создать новый, переместив в него содержимое из старого.

1) Почему бы сразу не создавать новый? Так же как NRVO это делает? Мы же про альтернативные изменения языка говорим, да?
2) Когда мы получаем из функции объект, на самом деле вызывающая сторона на своём фрейме выделяет память для этого объекта, и передаёт в вызываемую функцию адрес, куда помещать результат. Потом вызываемая там его создаёт, и отдаёт управление, а вызывающая начинает им владеть.
При NRVO компилятор так меняет код вызываемой функции, что объект, "копию" которого потом будут возвращать, создаётся сразу в переданном буфере, и потом он и остаётся в качестве результата функции.

Понятно, что эту пару механизмов (передача места под результат на внешнем фрейме через скрытый параметр и отображение разных видных как последовательно существующие копии объектов на один и тот же буфер) можно применять рекурсивно и многократно.


Как-то похоже работают и конструкторы, кстати.

То, что у нас, как программистов на С++ нет механизмов для прямого написания похожих функций, ну, например, мы не можем написать метод move_to_res(), который возвращает объект, в который перемещает себя.

Ну, то есть мы сейчас можем написать { return std::move(*this); }
Но для этого нам надо писать конструктор перемещения и всё такое. Напрямую мы такую функцию написать не можем.

Что касается критики идеи с методом move у вектора, то код

std::vector<T> dst;
src.move_to( dst )

ничем особо не хуже метода

std::vector<T> dst = std::move( src );

кроме того, что первое сразу понятно, а второе надо знать пр std::move, конструкторы перемещения и т. д...

Мало того, про метод move_to понятно что он делает, что делает конструктор перемещения коллекции понятно намного меньше.
Например, если посмотрим на std::basic_string<MyType>
Вполне легальна реализация std::basic_string, при которой не очень длинные строки лежат в буфере в самом объекте.
Вот конструктор перемещения такого состояния std::basic_string<MyType> должен звать конструкторы перемещения MyType или нет?
По уму если, должен, но зовёт ли?
И таких тонких мест -- куча ;(

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


BFE>std::string strResult = str1 + str2 + str3 + fun4(); // какая здесь проблема?
А зачем тут что-то, кроме RVO? Это всё и до move-семантики прекрасно работало...

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

VT>То, что при этом перемещение может и не произойти, то тут скорее будет вина принимающей стороны, а не функции move.


Я бы как-то move_ready назвал бы...

Здравствуйте, Пирожочек, Вы писали:

П>вот что дедушка пишет по этому поводу

move(x) means 'give me an rvalue reference to x.' That is, std::move(x) does not move anything; instead, it allows a user to move x. It would have been better if move() had been called rval(), but the name move() has been used for this operation for years

П>и я с ним полностью согласен. move ничего не мувает, а всего лишь кастит к rvalue-ссылке, поэтому название у функции не совсем корректно.

Раз дедушка высказался, хорошо бы узнать, что сказала бы бабушка. Наверное, предложила бы вместо forward() писать fref() . Заманчивая перспектива в программе вместо нормальных слов видеть набор заклинаний.

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

E>Так что и дальше можно обсуждать механизмы по управлению RVO...

Ну вот приведи разумный пример, когда RVO не нужна?

E>Конструктор копии был всегда, в отличии от. То, как сделали move-семантику, неизбежно приводит к тому, что она тихо и автоматически расползается по коду. Я считаю это одним из недостатков, а ты?

У меня ничего не расползается. Я давно на С++ и кодовая база у меня есть 10-ти летняя, большая, которая компилируется современным компилятором и работает. Ни разу проблем с move я там не встречал.

E>Даже это утверждение неверное, к сожалению. Я знаю примеры, когда дефолтный конструктор копии работает корректно, а дефолтный конструктор перемещения -- нет. Причём молча с очень отдалёнными последствиями.

Я вполне допускаю что такое может быть, иначе бы не было возможности определять/разрешать/запрещать copy/move по отдельности, но это говорит лишь о том, что либо у тебя очень специфический код, либо ты ходишь по тонкому льду вовсю используешь хаки и UB. В общем тут без маленького примера трудно судить.

E>Ну обычно оптимизация нужна в некоторых относительно редких местах, именно в них при случае контроль мог бы пригодиться. В остальных можно не делать ничего. Это, кстати, тоже не соответствует тому, как ввели move-семантику

По мне, так move ввели почти идеально и безболезненно, насколько это было возможно не поломав совместимость.

E>Я не предлагаю решение, я просто показываю, что то как сделали является вовсе не единственной альтернативой. На моё взгляд главная проблема, которую чинил move-конструктор -- это кривой дизайн std::vector со товарищи...
E>При этом его так и не выпрямили

Ну это все точно вкусовщина. Мне, например, вообще не очень нравится STL из-за концепции итераторов. Ты постоянно вынужден следить за их валидностью, за совместимостью, что бы один указывал перед другим и т.д. Получается адское дублирование кода. В элементарных операциях просто безумное количество параметров.

Здравствуйте, 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) Вынуждает заводить лишние локальные переменные, что крайне плохо сказывается на структуре кода.

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

E>...

Не ну критиковать легко конечно, но давай посмотрим что ты предлагаешь и какой синтаксис:
Ты предлагаешь, грубо говоря, src.move(dst);

Т.е. dst уже ложен быть на момент создания. А как через такой синтаксис выразить:

SomeClass b = ....
//...
SomeClass a = b + SomeClass(...); // такое?

SomeClass a = ....
func(std::move(a)); // такое?

А что делать если нам не повезло и у dst нет конструктора по умолчанию? И src у тебя превращается в такое же зомби с неопределенным состоянием. Так чем же твой подход лучше?

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

BFE>>std::string strResult = str1 + str2 + str3 + fun4(); // какая здесь проблема?
E>А зачем тут что-то, кроме RVO? Это всё и до move-семантики прекрасно работало...

Причём тут RVO? Или это вы так copy elision называете?

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

E>То, что у нас, как программистов на С++ нет механизмов для прямого написания похожих функций, ну, например, мы не можем написать метод move_to_res(), который возвращает объект, в который перемещает себя.
E>Ну, то есть мы сейчас можем написать { return std::move(*this); }
E>Но для этого нам надо писать конструктор перемещения и всё такое. Напрямую мы такую функцию написать не можем.
Можем:

#include <memory>
#include <iostream>
using namespace std;

class A
{
public:
  A(){}
  A(A&&)=delete;
  A&& move_me(){return std::move(*this); }
};

int main() {
    
  A a;
    
  A&& rrA = a.move_me();
    
  std::cout << "ok\n";
  return 0;
}

E>Что касается критики идеи с методом move у вектора, то код

std::vector<T> dst;
E>src.move_to( dst )

ничем особо не хуже метода

std::vector<T> dst = std::move( src );

кроме того, что первое сразу понятно, а второе надо знать пр std::move, конструкторы перемещения и т. д...
А как быть, если dst — аргумент функции?

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

A> Видел. Не очень-то с ними разбираются. Просто действуют, предполагая, что худший сценарий возможен, выдавая диагностику, если указатель провис в хотя бы одной из веток условия. Для вызова методов возможно перемещенного объекта по логике то же самое наверное предлагается.

Понятно, что чудес ждать не стоит. Но вы сами считаете следующий код корректным?

void test(bool condition)
{
    A a,b;
    if(condition)
    {
        b = std::move(a);    
    }    
    a.doSomething();
}

Я бы не отказался от предупреждений компилятора для случая вызова метода возможно перемещённого объекта(равно как и возможно удалённого). Что вы предлагаете делать в таких ситуациях?

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

R>Всем привет!

Всем привет в чатике!

R>Вопрос несколько философский. Правомерно ли делать какие-либо допущения о состоянии объета, в самом общем случае, после того, как его содержимое было перемещено? Разумеется, состояние объекта должно позволять разрушить этот объект, это сомнению не прдвергается. Но достаточно ли этого? Ведь помимо физического тела у объекта есть еще и логическое состояние — его душа, так сказать. Так вот как быть с ней — нужно ли заботиться о том, чтобы после перемещения объект оставался в целостном состоянии с точки зрения логики программы — на тот случай, если кому-то захочется продолжать пользоваться объектом после его перемещения?

Философия есть в том, что у объекта (особенно, у контейнера) есть общая и частная семантика.
Например, пустой и непустой контейнер, нулевой и ненулевой указатель.

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

После точки move мы требования убираем: содержимое (какое бы оно ни было) утилизировано (каким бы способом это ни было сделано).
В твоём случае с регистрацией:

void register(shared_ptr<R> smth);

void init() {
  shared_ptr<R> r(new R);
  shared_ptr<R> shadow = r;
  somehow_setup(*r);
  register(r);  // move подразумевается, но синтаксически не оформлено
  change_something(*r); // а регистратор-то готов к тому, что мы что-то на ходу поменяли?
  // а даже если бы и было настоящее move c обнулением источника, то что?
  change_something(*shadow);
  // а даже если и на чтение: регистратор же может отдать содержимое в распоряжение другого потока...
  read_something(*shadow);
}

То есть, философский вопрос здесь не о теле и душе, а о том, как далеко по ссылкам и указателям можно лазать шаловливыми руками.

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

VT>Я бы не отказался от предупреждений компилятора для случая вызова метода возможно перемещённого объекта(равно как и возможно удалённого). Что вы предлагаете делать в таких ситуациях?


Да я только за на самом деле . Конечно, полезно будет.

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

V>Если контейнеру не нужно перемещать ваши объекты, то он будет сам mov-ваться при передачи и возврате по значению.
В нормальных программах большие контейнеры не копируют без нужды. И не надо забывать про RVO при этом.


E>>Ну метод move вместо присваивания, которое не всегда очевидно в этом месте copy или move, разве это сложнее синтаксис? Наоборот понятнее что код делает...
V>Если у вас старый код, то вам не нужно об этом думать, всегда будет копирование.
При чём тут старый код или новый. Мы же про "понятнее", а не про старый код?..

Вообще я иначе как-то воспринимаю мир.
Надо посмотреть какие сценарии мы хотим улучшить или даже поддержать с move-семантикой, и посмотреть какие есть альтернативы.

Я вижу три группы сценариев:

1) Оптимизация передачи параметров/значений в/из функции.
2) Оптимизация STL-коллекций в сторону поддержки возможности move значений в другую коллекцию и при переаллокации буфера.
3) Всякая мелочёвка со связыванием r-value с неконстантными ссылками

И есть ещё один новый сценарий -- объекты с невозможностью создания копий, но с возможностью эстафетного копирования.

Вот и надо смотреть что и как можно было сделать в каждом из этих 4 сценариев в тех областях, в которых применяется С++, а не пилить универсальный всемогутер с не до конца понятными последствиями применения.

E>>Зачем? Какие сценарии хочется поддержать?
V>Например, оптимальная передача параметров в функцию, не зависимо от того какой тип параметра передается.
Ну, то есть, мы хотим написать шаблон функции, в которой мы говорим что-то типа "первый параметр -- это MyType, но ссылка или копия зависит от того, что удобнее вызвать?
Вообще не совсем понятно, что тут означает слово "оптимальная"



E>>Что значит "не получилось"?
V>Я не спец по компиляторам, но RVO/NRVO возможно не всегда. В этом случае следующим методом по очереди будет move.
Ну, на мой взгляд это надо обсуждать более предметно.

E>>RVO/NRVO, по сути, это просто неявная передача в функцию адреса буфера, в котором надо создать результат + такая модификация кода функции компилятором, что бы результат создавался по этому адресу.
V>Все верно.
Ну то есть это синтаксический сахар над след. конструкцией:

void f( void* to_fill )
{
    // тут код, вычисляющий какие-то params
    ::new( to_fill ) ResType( params ) 
}

и верная передача владения объектом между фреймами разных функций?
Почему это нельзя полостью контролировать средствами языка, а не в режиме "иногда не получается"?

E>>

---

V>Ну С++ не требует от вас использовать move, куда уж прозрачнее . Move нужен тех случаев, где он нужен и приносит выгоду, а также для явного выражения семантики объектов, которые принципиально не копируемые. Теперь, если нужно, это можно выразить явно и компилятор все будет проверять за вас.
Да враньё всё это. Идеологические утверждения не подтверждаемые практикой. Так же как слабая и сильная готовность к исключениям и прочие идеи про бесплатные полуживые объекты.

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

E>>Разве вставка не в конец в std::vector сейчас не через цепочку move-конструкторов/присваиваний работает?
BFE>Да, это так. Используется std::move_backward. Об этом я узнал только сейчас (или я забыл о том, что это знал), когда полез в исходники и посмотрел. В работе я этого не замечал, что, кстати, говорит в пользу move семантики.

Я знал, это, тем не менее, не делает move-семантику лучше, с моей точки зрения
На это можно посмотреть иначе. Я вообще считаю, что С++ очень сильно переусложнён и концептуально и синтаксически и по всякому.
И всякое доп. усложнение, особенно концептуальное, ОЧЕНЬ ДОРОГО СТОИТ. Ну и должно дофига всего давать...

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

E>>Так что и дальше можно обсуждать механизмы по управлению RVO...
V>Ну вот приведи разумный пример, когда RVO не нужна?
Не понял, что значит "не нужна"?

V>У меня ничего не расползается. Я давно на С++ и кодовая база у меня есть 10-ти летняя, большая, которая компилируется современным компилятором и работает. Ни разу проблем с move я там не встречал.

"Давно" тут не главное, главное -- большой проект, много людей и т. д...

V>Я вполне допускаю что такое может быть, иначе бы не было возможности определять/разрешать/запрещать copy/move по отдельности, но это говорит лишь о том, что либо у тебя очень специфический код, либо ты ходишь по тонкому льду вовсю используешь хаки и UB. В общем тут без маленького примера трудно судить.

Ну я же приводил пример. У тебя есть авторегистрилки и уведомлялки.
Когда ты из них выводишь объекты, которые получают и рассылают эти все уведомления, и потом их копируешь дефолтным конструктором копии, то в момент создания копии весь оригинал ещё существует в виде MDT, и он весь корректно работает и все рассылки уведомлений между его частями тоже. А когда ты перемещаешь конструктором перемещения, то в процессе перемещения какие-то части уже подписаны, а какие-то ещё нет, в результате инварианты вроде "всех уведомили о" могут теряться...
И да, в оригинальном коде, как и в версии с перемещениями, никаких хаков, UB, "тонких льдов" и т. п. Чистая бизнес-логика, простые компактные инструменты и т. д...

V>По мне, так move ввели почти идеально и безболезненно, насколько это было возможно не поломав совместимость.
Очевидно самый безболезненный вариант -- ничего вообще не вводить, как минимум для тех случаев, в которых оптимизация не нужна
Я понял в чём суть разногласий. Ты считаешь, что move-семантику ввели практически за бесплатно, а я считаю, что усложнили и весьма заметно, язык.

V>Ну это все точно вкусовщина. Мне, например, вообще не очень нравится STL из-за концепции итераторов. Ты постоянно вынужден следить за их валидностью, за совместимостью, что бы один указывал перед другим и т.д. Получается адское дублирование кода. В элементарных операциях просто безумное количество параметров.

Да, STL -- штука весьма кривая. Это правда.