вот почему я хочу быть в чате с людьми, которые понимают, как это работает

эти же люди и в #supapro сидят, когда время появляется и желание помочь

в супапро помимо этого наверняка много вопросов которые еще ниже

кстати зайду я туда может сам смогу чем-то помочь чувакам

ну вот такого типа

Можете подсказать какие библиотеки важны в с++ и какие стоит изучить в первую очередь

вот поэтому лучше тут чем не тут.

у меня хотя бы вопросы конкретные...

Можете подсказать какие библиотеки важны в с++ и какие стоит изучить в первую очередь

некоррекный вопрос, используй (и соответственно изучи) те, которые используешь для решения задачи

некоррекный вопрос, используй (и соответственно изучи) те, которые используешь для решения задачи

это ты не мне говори, это чувак из другой конфверенции.

я привел это как пример тупого вопроса

сорри, не понял

не за что

кстати мнения немножко разделились

вот Андрей считает что мув надо указывать эксплсит если это важно. (но рво и так позаботится) ты считаешь, что можно не паритсья, и точно позаботится

что так или иначе произойдет или рво, или мув

что так или иначе произойдет или рво, или мув

на рво не надейся, сам не плошай

return value optimization - это оптимизация, которую компилятор МОЖЕТ сделать

да, но вот вопрос

насколько часто он делает на практике?

std::vector<> v = std::move(muFunc());

Не нужно так писать

Не нужно так писать

откуда ты знаеш

инлайн - тоже операция, которую компилятор МОЖЕТ сделать, но это же не повод форсинлайнить все вручную

std::move явно здесь не нужен

Не нужно так писать

а как нужно?

std::move явно здесь не нужен

чойт

я бы вообще не парился и делал всё в на куче

поскольку myFunc возвращает временный объект, который подходит под vector&&

http://stackoverflow.com/a/17473869

окей, это тот самый ответ который я хотел слышать

и заворачивал в уник поинторы

и бед не знал бы

а как нужно?

Вы таким образом явно убиваете возможность rvo, которое быстрее move.

компилятор не дедуцирует, что мув нафиг не нужен и не поступает по-своему?

я вот почему-то думаю, что должен

поскольку myFunc возвращает временный объект, который подходит под vector&&

Да, но вот из самой функции return std::move(vec);

При этом надо делать

само собой

что вообще из себя представляет вызов std::move()?

это враппер или абстракция компилятора?

я вот почему-то думаю, что должен

Эээ, вы ему явно говорите мувать, а он такой, не, я лучше тут копи элизион запилю.

что вообще из себя представляет вызов std::move()?

ничего, это просто каст к T&&

понял

это заставляет компилятор перенести состояние одного объекта в другой

после std::move(object) object уже не будет владеть состоянием, которым владел до мува

Погодите, что за бред. Какой return std::move(); для локального вектора.

в общем, в моем конкретном случае мне стоит не громоздить и полагаться на RVO до тех пор, пока профайлинг не скажет, что это, чувак, было плохо

Приеду майерса открою.

локальй вектор и std::move

нормально

Просто возврат по значению хорошо сработать должен.

блин, какая интересная тема

вопрос из основ, а мнений минимум два

а нет, три точно есть

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

Просто возврат по значению хорошо сработать должен.

с чего бы это?

локальный объект != временный

Погодите, что за бред. Какой return std::move(); для локального вектора.

return vec; будет подвергнут copy elision

что плохого если он зделает данные в куче и вернёт уник поинтор?

мувнет

это пижже рво?

return std::move(vec); не будет

что плохого если он зделает данные в куче и вернёт уник поинтор?

я так и делал

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

отсюда и вопрос

это пижже рво?

Нет, вы возвращаете и копируете указатель.

return std::move(vec); не будет

Так копи элижн это хорошо, почему вы пытаетесь быть умнее компилятора

Нет, вы возвращаете и копируете указатель.

уник поинтор нескопировать

уник поинтор нескопировать

Сам указатель, адрес.

Так копи элижн это хорошо, почему вы пытаетесь быть умнее компилятора

Копи элижн это хорошо.

Сам указатель, адрес.

да, его копируем, это хор

Никто не спорит.

при rvo у вас передается указатель в стек фрейм вызова и все.

Я просто говорю, что можно зафорсить move.

Вот таким способом.

А так да, конечно RVO это круто.

Зафорсить можно, но не нужно.

Иногда нужно.

кстати если конкретнее то я возвращаю не вектор

я возвращаю map map'ов

вопрос: все еще никаких осложнений?

все нормально

Если возможно, то будет копи элижн и это хорошо, если невозможно без всяких мув будет мув-конструктор.

Покуда он у тебя на локальном стеке был создан — всё ок.

ну вот и мне показалос. контейнер он и есть контейнер

Если он создан на стеке глубже — уже не факт.

Если возможно, то будет копи элижн и это хорошо, если невозможно без всяких мув будет мув-конструктор.

В такой ситуации копи элижн будет всегда.

Если он создан на стеке глубже — уже не факт.

а разве он не передастся наверх рекурсивно?

из скоупа в скоуп

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

Если возможно, то будет копи элижн и это хорошо, если невозможно без всяких мув будет мув-конструктор.

std::move(local) - поддерчикает твое намерение зафорсить передачу состояния, он не помешает RVO

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

ну да, это хорошо тем, что недвусмысленно, понимаю

std::move(local) - поддерчикает твое намерение зафорсить передачу состояния, он не помешает RVO

Помешает, увы.

std::move(local) - поддерчикает твое намерение зафорсить передачу состояния, он не помешает RVO

Он реально помешает

а разве он не передастся наверх рекурсивно?

Не, оно то может и передаётся, но я не уверен, что в плюсах по цепочке вызовов будет RVO

Из одной функции точно будет.

ну, как я понимаю, там может оказаться имплисит мув рано или поздно

если коллстек глубоко

что в общем-то тоже неплохо

ну, как я понимаю, там может оказаться имплисит мув рано или поздно

Зависит от семантики объекта. Anyway компилятор скажет, если забыл что-то определить.