а как сообщить разрабам VC++ о косяке в их реализации stl?

Написать Стефану?

А еще лучше Billy O’Neal

А еще лучше Billy O’Neal

Звучит как хорошее название для ирландского паба

Имеем: https://pastebin.com/469tzae0 Будет ли здесь заюзано copy elision\NRVO\move? Стандарт С++11. Если в С++14 что то изменилось по этому поводу, то тоже интересно.

Если шо, wstr.str() имеет возвращаемый тип wstring.

почти уверен, что будет decltype(str()) же внутренний тип, а не аллоцируется заново

почти уверен, что будет decltype(str()) же внутренний тип, а не аллоцируется заново

хреновый конечно пруф, но все же: https://godbolt.org/g/y22kZw

почти уверен, что будет decltype(str()) же внутренний тип, а не аллоцируется заново

Не понял, что ты хотел сказать))

Имеем: https://pastebin.com/469tzae0 Будет ли здесь заюзано copy elision\NRVO\move? Стандарт С++11. Если в С++14 что то изменилось по этому поводу, то тоже интересно.

Скорее всего будет RVO, если не получится то будет move строчки. В C++17 RVO гарантируется.

https://ideone.com/WavYix

WHYYYYYYYYYYYYYY

https://ideone.com/WavYix

и зачем это здесь?

https://ideone.com/WavYix

Сегодня на уроке мы изучаем условный оператор.

WHYYYYYYYYYYYYYY

else аттачится к ближайшему if того же уровня

Сегодня на уроке мы изучаем условный оператор.

грамматику глянуть не пробовали?

грамматику глянуть не пробовали?

Пробовали.

Скорее всего будет RVO, если не получится то будет move строчки. В C++17 RVO гарантируется.

Copy elision здесь не будет

Copy elision здесь не будет

А move?

Copy elision здесь не будет

Будет. https://godbolt.org/g/KoGXUd

А move?

Без явного указания не будет

Без явного указания не будет

А если добавить локальный объект result, присвоить ему wstr.str() и сделать return result, то будет nrvo\move?

Пробовали.

и чо там, однозначно всё?

Звучит как хорошее название для ирландского паба

Таких людей нужно знать в лицо

Таких людей нужно знать в лицо

На ирландца он не похож :)

Будет. https://godbolt.org/g/KoGXUd

интересно...

Будет. https://godbolt.org/g/KoGXUd

действительно. не будет, если ссылку возвращать.

А если добавить локальный объект result, присвоить ему wstr.str() и сделать return result, то будет nrvo\move?

будет nrvo в таком случае, но не нужно, ибо copy elision (я ошибся выше)

будет nrvo в таком случае, но не нужно, ибо copy elision (я ошибся выше)

То, что в 17 стандарте будет copy elision, я и не сомневался. Вопрос был про c++11/14

Конкретно по ссылке выше, если сделать 11 стандарт, будет ошибка компиляции

в 11/14 он может быть, но не обязателен. как я понимаю

То, что в 17 стандарте будет copy elision, я и не сомневался. Вопрос был про c++11/14

а там никто не гарантирует. на моей памяти, в случае не срабатывания NRVO/RVO идёт копия (само не мувнется)

а там никто не гарантирует. на моей памяти, в случае не срабатывания NRVO/RVO идёт копия (само не мувнется)

Насколько я знаю, если nrvo не срабатывает, но формальные условия nrvo соблюдены, то компилятор трактует возвращаемое значение как rvalue.

Насколько я знаю, если nrvo не срабатывает, но формальные условия nrvo соблюдены, то компилятор трактует возвращаемое значение как rvalue.

Сомнительно

Сомнительно

Взято отсюда: http://en.cppreference.com/w/cpp/language/return If expression is an lvalue expression and the conditions for copy elision are met, or would be met, except that expression names a function parameter, then overload resolution to select the constructor to use for initialization of the returned value is performed twice: first as if expression were an rvalue expression (thus it may select the move constructor or a copy constructor taking reference to const), and if no suitable conversion is available, overload resolution is performed the second time, with lvalue expression (so it may select the copy constructor taking a reference to non-const). The above rule applies even if the function return type is different from the type of expression (copy elision requires same type)

То есть как я понял, при первой попытке перегрузки он может применить move конструктор

У Майерса тоже про это было

я так лабу сдавал

same shit :(

17 стандарт устраняет неоднозначность относительно copy elision?

17 стандарт устраняет неоднозначность относительно copy elision?

Да. Теперь обязательно везде.

Хелло, есть кто проконсультирует по поводу arm-linux-gnueabihf-g++?

Для результата-структуры только не уверен, будет ли работать

64-битный констэкспр-хеш посчитай от структуры, тогда в шаблон влезет

Да. Теперь обязательно везде.

Нет. Guaranteed copy elision в C++17 применимо только к подмножеству случаев когда разрешается copy elision. Например, с NRVO ничего не поменялось.

Нет. Guaranteed copy elision в C++17 применимо только к подмножеству случаев когда разрешается copy elision. Например, с NRVO ничего не поменялось.

Ага, вроде только для prvalue (но саму категорию prvalue немного расширили)

Написать Стефану?

Спасибо, я наверное все-таки в developer community сделаю тикет

Ага, вроде только для prvalue (но саму категорию prvalue немного расширили)

Точнее ее не расширили, а поменяли смысл самой категории. Если раньше prvalue символизировал временный объект, то теперь это просто нечто из чего временный объект можно создать когда потребуется.

Нет. Guaranteed copy elision в C++17 применимо только к подмножеству случаев когда разрешается copy elision. Например, с NRVO ничего не поменялось.

Прочти моё сообщение про nrvo выше и скажи прав ли я, по твоему мнению?))

Прочти моё сообщение про nrvo выше и скажи прав ли я, по твоему мнению?))

Да, если возвращается локальный объект и не параметр catch блока.

кажется в c++20 хотят какой-то рефлекшн времени компиляции запилить. чуть ли не через constexpr.

Хотят, но будет к c++23 в лучшем случае

Имеем: https://pastebin.com/469tzae0 Будет ли здесь заюзано copy elision\NRVO\move? Стандарт С++11. Если в С++14 что то изменилось по этому поводу, то тоже интересно.

Нет, не будет Стандартом на данный момент хапрещено делать copy elision Но мы работаем над этим https://stdcpp.ru/proposals/e6263404-2b60-49af-87c6-bd9bc1801257

народ, кому не лень сейчас поставить arm-linux-gnueabihf-g++ и проверить одну багу? Сделаем хорошо комьюнити

17 стандарт устраняет неоднозначность относительно copy elision?

Только для prvalue Другими словами, если переменная без имени присваивается в переменную с именем и только

Нет, не будет Стандартом на данный момент хапрещено делать copy elision Но мы работаем над этим https://stdcpp.ru/proposals/e6263404-2b60-49af-87c6-bd9bc1801257

4 пункт ломает существующий код! Я всё помню! ? код с замерами времени выполнения функций.

4 пункт ломает существующий код! Я всё помню! ? код с замерами времени выполнения функций.

Всё верно

Продумываю этот кейс

А первый пункт, кажется ни у кого ничего не ломает гарантированно. Ну и избавляет от дурного влияние std::move на компилятор. Если хотя бы он войдет - будет уже неплохо. IMHO. А то по коду периодически ловлю мувы где они вредят.

А первый пункт, кажется ни у кого ничего не ломает гарантированно. Ну и избавляет от дурного влияние std::move на компилятор. Если хотя бы он войдет - будет уже неплохо. IMHO. А то по коду периодически ловлю мувы где они вредят.

А есть что годного почитать про вредные мувы? А то на встрече это упоминалось, но логики когда нужен return move(x) а когда сойдет просто return x я не уловил(

и про std::forward не забывайте.

народ, кому не лень сейчас поставить arm-linux-gnueabihf-g++ и проверить одну багу? Сделаем хорошо комьюнити

и что там?

А есть что годного почитать про вредные мувы? А то на встрече это упоминалось, но логики когда нужен return move(x) а когда сойдет просто return x я не уловил(

У Майерса есть про это в "Эффективный и современный с++" в русской версии у меня обсуждение начинается на 179 странице

и про std::forward не забывайте.

Есть кейсы, где он нужен, кроме Args&&...args -> std:forward<Args>(args)...?

ERROR: S client not available

Есть кейсы, где он нужен, кроме Args&&...args -> std:forward<Args>(args)...?

Из пары видеороликов я так понял, его надо использовать вместо move.

шта?

когда вы имеете тип Т, например так template <typename T> void f(T&& t); вы не можете быть уверены, T это rvalue или lvalue, тут вместо std::move нужно всегда использовать std::forward<T>

но это же и есть perfect forwarding.

http://thbecker.net/articles/rvalue_references/section_08.html

Не надо путать std::move, std::forward, X{}, T и T&&.

когда вы имеете тип Т, например так template <typename T> void f(T&& t); вы не можете быть уверены, T это rvalue или lvalue, тут вместо std::move нужно всегда использовать std::forward<T>

t это всегда lvalue, передача по значению. forward используется только при использовании universal reference

да, я исправил

не сразу заметил)

Чувствую, std::move vs std::forward в коде будет предметом тех еще холиворов.

При чем тут холивары? Это разные инструменты.

После 15 лет в индустрии меня раздражает множество мелочей.

Для того и нужны специалисты, чтобы разбираться в мелочах.

В частности, очень не люблю объявление нескольких переменных в одной строчке. Копипастишь, и раздражает потом вырезать лишние переменные. Так и здесь. Буду копипастить темплейты, а там вместо move надо будет forward. Неужели прошлый программист сразу не мог написать forward??

А есть что годного почитать про вредные мувы? А то на встрече это упоминалось, но логики когда нужен return move(x) а когда сойдет просто return x я не уловил(

если тип переменной не отличается от типа возвращаемого значения: struct foo{}; foo f1() { foo f; return f; // не надо } foo f2(foo f) { return f; // не надо } foo f3(foo& f) { return std::move(f); // надо } если тип переменной отличается от типа возвращаемого значения, всегда надо move

Clang -Wpessimizing-move https://godbolt.org/g/xkS6KE

если тип переменной не отличается от типа возвращаемого значения: struct foo{}; foo f1() { foo f; return f; // не надо } foo f2(foo f) { return f; // не надо } foo f3(foo& f) { return std::move(f); // надо } если тип переменной отличается от типа возвращаемого значения, всегда надо move

а почему в первых двух случаях не надо? Из-за NRVO?

если тип переменной не отличается от типа возвращаемого значения: struct foo{}; foo f1() { foo f; return f; // не надо } foo f2(foo f) { return f; // не надо } foo f3(foo& f) { return std::move(f); // надо } если тип переменной отличается от типа возвращаемого значения, всегда надо move

есть 1 исключение если это юник птр например и ты из фабрики возвращаешь юник на интерфейс, но реально на наследника. типы разные, но для читаемости лучше кастить, а не мувать

если тип переменной не отличается от типа возвращаемого значения: struct foo{}; foo f1() { foo f; return f; // не надо } foo f2(foo f) { return f; // не надо } foo f3(foo& f) { return std::move(f); // надо } если тип переменной отличается от типа возвращаемого значения, всегда надо move

идеальное объяснение. Надо в закладки добавить

Может в 3 случае сразу принимать foo&&?

Кстати, раз тут второй день про copy elision обсуждение, есть ли красивые способы вот здесь сегфолт убрать? https://onlinegdb.com/S13BSkFb7

а почему в первых двух случаях не надо? Из-за NRVO?

Тут хорошо расписано: http://vmpstr.blogspot.com/2015/12/redundant-stdmove.html Краткий ответ, да, если может быть применено nrvo — return statement аргументом которого является локальная переменная или параметр функции (возможно, окруженные скобками), то value category выражения автоматически меняется с lvalue на xvalue.

Ой, xvalue что ? Ни то, ни сё, что угодно?

Может в 3 случае сразу принимать foo&&?

нет, тогда нельзя будет передать lvalue. Universal reference - это к шаблонам относится, потому что там есть сворачивание ссылок

хм, интересноый варнинг выдает gcc 8.1 на код auto f(auto &&s) { return std::move(s); } [x86-64 gcc 8.1 #1] warning: use of 'auto' in parameter declaration only available with -fconcepts Разве это доступно не с C++14? На gcc 7 такого нет

Ой, xvalue что ? Ни то, ни сё, что угодно?

Грубо говоря, да. An xvalue is a glvalue that denotes an object or bit-field whose resources can be reused (usually because it is near the end of its lifetime).

хм, интересноый варнинг выдает gcc 8.1 на код auto f(auto &&s) { return std::move(s); } [x86-64 gcc 8.1 #1] warning: use of 'auto' in parameter declaration only available with -fconcepts Разве это доступно не с C++14? На gcc 7 такого нет

если это функция, а не лямбда, то вроде не робит

для параметров

если это функция, а не лямбда, то вроде не робит

даже с -pedantic робит: https://godbolt.org/g/B7QpEx