Насколько вы полагаетесь на оптимизацию компилятора ?
Скажем даже MSVC подтянулся с оптимизацией: MSVC Improving Copy and Move Elision.
Однако, стандарт не гарантирует нам отсутствие копирования в отличии от гарантий временного объекта.
В идеале хотелось бы проверку на этапе компиляции в отсутствии копирования.
С другой стороны, можно всегда приводить к rvalue и получить гарантировано отсутствие копирования, правда с гарантированным перемещением, которого не будет в случае NRVO.
struct MyType { ... };
MyType might_copy() {
MyType m;
// много-много кодаreturn m;
}
MyType always_move() {
MyType m;
// много-много кодаreturn std::move(m);
}
Здравствуйте, _NN_, Вы писали:
_NN>С другой стороны, можно всегда приводить к rvalue и получить гарантировано отсутствие копирования, правда с гарантированным перемещением, которого не будет в случае NRVO.
Если компилятор не смог NRVO, то он и так будет пытаться сделать через move (если он нормальный компилятор, конечно). Так что смысла в return std::move(...) нет если типы одинаковые.
А вот это как раз то, чего делать не стоит. Здесь и без std::move копмилятор будет использовать перемещение. И это не какая-то там оптимизация, а требование стандарта языка:
Здравствуйте, reversecode, Вы писали:
R>вообще забудьте за это R>начиная с с++17 изза кажеться полухина R>теперь везде сopy elision
Да как бы не так. Copy elision вытеснил только RVO, а NRVO как был оптимизацией, так и осталсся. И требует доступности move семантики. Вот здесь пример: http://rsdn.org/forum/cpp/8702330.1
R>This variant of copy elision is known as NRVO, "named return value optimization." In the initialization of an object, when the source object is .
Угу, и называется это non-mandatory copy/move elision. Ты заголовок-то прочитай, на который ссылку даешь.
Ты понимаешь смысл слов "non-mandatory" и "optimization"? Если не понимаешь, то я поясню — это означает, что компилятор может выполнить эту ОПТИМИЗАЦИЮ, а может не выполнить — по своему усмотрению. Поэтому и доступность move семантики для NRVO является обязательной. В отличие от mandatory copy/move elision, которая позволяет возвращать по значению объекты non-copyable and non-moveable классов.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, _NN_, Вы писали:
_NN>MyType always_move() { _NN> MyType m; _NN> // много-много кода _NN> return std::move(m); _NN>} _NN>[/c]
Кстати если у класса нет отдельного мув-конструктора, но есть свой копи-конструктор (а в древнем проекте, написанном до 11 года, это вполне вероятно), то мув по дефолту делается через копирование. Так что есть риск что будет лишнее копирование
Здравствуйте, reversecode, Вы писали:
R>я просто не верю в мифы про немножко беременность R>и если компилятор может сделать какую то хрень R>то он ее обязательно сделает и сделает как можно чаще
Вот так можно (mandatory copy/move elision, aka RVO):
MyType might_copy() {
return MyType{};
}
А вот так нельзя (non-mandatory copy/move elision, aka NRVO):
MyType might_copy() {
MyType m;
// много-много кодаreturn m; // error: use of deleted function 'MyType::MyType(MyType&&)'
}
И в этом принципиальное отличие RVO от NRVO и обязательного требования от оптимизации. А ты мне тут про какую-то свою веру рассказываешь
Изменения в части copy/move elision коснулись только RVO — оно перестало быть оптимизацей и стало обязательным требованием. А NRVO как было необязательной оптимизацей в C++03, так и осталось необязательной оптимизацией в C++23.
--
Не можешь достичь желаемого — пожелай достигнутого.
R>А вот это как раз то, чего делать не стоит. Здесь и без std::move копмилятор будет использовать перемещение. И это не какая-то там оптимизация, а требование стандарта языка:
используешь std::move, ты эту возможность отсекаешь.
Точно ли стандарт гарантирует использование конструктора перемещения прежде всего или всё же на усмотрение компилятора ?
Здравствуйте, _NN_, Вы писали:
_NN>Точно ли стандарт гарантирует использование конструктора перемещения прежде всего или всё же на усмотрение компилятора ?
По крайней мере, если полагаться на формулировки стандартов С++17 и C++20, то точно, (хотя они и несколько отличаются друг от друга):
Здесь, конечно, здорово сбивает столку фраза "might be" в первом предложении абзаца:
An implicitly movable entity is a variable of automatic storage duration that is either a non-volatile object or an rvalue reference to a non-volatile object type. In the following copy-initialization contexts, a move operation might be used instead of a copy operation...
Но если прочитать абзац до конца, становится понятно, что это "might be" вовсе не является эквивалентом "на усмотрение компилятора", а относится к различным возможным исходам достаточно четко описанной процедуры, которую должен выполнить компилятор:
overload resolution to select the constructor for the copy or the return_value overload to call is first performed as if the expression or operand were an rvalue. If the first overload resolution fails or was not performed, overload resolution is performed again, considering the expression or operand as an lvalue. [ Note: This two-stage overload resolution must be performed regardless of whether copy elision will occur. It determines the constructor or the return_value overload to be called if elision is not performed, and the selected constructor or return_value overload must be accessible even if the call is elided. — end note]
То есть, компилятор ДОЛЖЕН сперва попытаться обработать выражение под return как rvalue и только затем уже как lvalue. Тут нужно заметить, что если на первом шаге находится конструктор перемещения, который явно помечен как удаленный, то вторая попытка даже не выполняется.
В С++23 снова перетасовали все формулировки, снова нужно разбираться, чтоб понять, что именно изменилось. Но я не думаю, что этот принцип будет отменен.
P.S. Ну и такое еще, чисто обывательское соображение: это было бы совсем странно, если бы они требовали обязательной доступности семантики перемещения объекта в условиях, когда попытка использования этой самой семантики не является обязательной.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, T4r4sB, Вы писали:
TB>Кстати если у класса нет отдельного мув-конструктора, но есть свой копи-конструктор (а в древнем проекте, написанном до 11 года, это вполне вероятно), то мув по дефолту делается через копирование. Так что есть риск что будет лишнее копирование
Да, но в этом случае и использование std::move ничего не изменит. В этой же теме, как я понял, главный вопрос — нужно использовать std::move в return expression, или не нужно.
--
Не можешь достичь желаемого — пожелай достигнутого.
