babysitter
Погодите, что за бред. Какой return std::move(); для локального вектора.
Micktu 😬
в общем, в моем конкретном случае мне стоит не громоздить и полагаться на RVO до тех пор, пока профайлинг не скажет, что это, чувак, было плохо
babysitter
Приеду майерса открою.
Anatoly
локальй вектор и std::move
Anatoly
нормально
babysitter
Просто возврат по значению хорошо сработать должен.
Micktu 😬
блин, какая интересная тема
Micktu 😬
вопрос из основ, а мнений минимум два
Micktu 😬
а нет, три точно есть
Surreal
Потому что реализация не стандартизована.
Anatoly
локальный объект != временный
Andrei
Погодите, что за бред. Какой return std::move(); для локального вектора.
return vec; будет подвергнут copy elision
Deleted Account
что плохого если он зделает данные в куче и вернёт уник поинтор?
Deleted Account
мувнет
Deleted Account
это пижже рво?
Andrei
return std::move(vec); не будет
Micktu 😬
сейчас задался вопросом могу ли я не городить в кучу и вернуть значение
Micktu 😬
отсюда и вопрос
babysitter
return std::move(vec); не будет
Так копи элижн это хорошо, почему вы пытаетесь быть умнее компилятора
Andrei
Никто не спорит.
Surreal
при rvo у вас передается указатель в стек фрейм вызова и все.
Andrei
Я просто говорю, что можно зафорсить move.
Andrei
Вот таким способом.
Andrei
А так да, конечно RVO это круто.
babysitter
Зафорсить можно, но не нужно.
Andrei
Иногда нужно.
Micktu 😬
кстати если конкретнее то я возвращаю не вектор
Micktu 😬
я возвращаю map map'ов
Micktu 😬
вопрос: все еще никаких осложнений?
Anatoly
все нормально
babysitter
Если возможно, то будет копи элижн и это хорошо, если невозможно без всяких мув будет мув-конструктор.
Andrei
Покуда он у тебя на локальном стеке был создан — всё ок.
Micktu 😬
ну вот и мне показалос. контейнер он и есть контейнер
Andrei
Если он создан на стеке глубже — уже не факт.
Andrei
Если возможно, то будет копи элижн и это хорошо, если невозможно без всяких мув будет мув-конструктор.
В такой ситуации копи элижн будет всегда.
Micktu 😬
из скоупа в скоуп
Andrei
Но это всё равно не избавляет от надобности написать move или copy конструктор, не смотря на то, что он даже не вызывается.
Anatoly
Если возможно, то будет копи элижн и это хорошо, если невозможно без всяких мув будет мув-конструктор.
std::move(local) - поддерчикает твое намерение зафорсить передачу состояния, он не помешает RVO
Micktu 😬
Но это всё равно не избавляет от надобности написать move или copy конструктор, не смотря на то, что он даже не вызывается.
ну да, это хорошо тем, что недвусмысленно, понимаю
Andrei
babysitter
Andrei
а разве он не передастся наверх рекурсивно?
Не, оно то может и передаётся, но я не уверен, что в плюсах по цепочке вызовов будет RVO
Andrei
Из одной функции точно будет.
Micktu 😬
ну, как я понимаю, там может оказаться имплисит мув рано или поздно
Micktu 😬
если коллстек глубоко
Micktu 😬
что в общем-то тоже неплохо
Andrei
ну, как я понимаю, там может оказаться имплисит мув рано или поздно
Зависит от семантики объекта. Anyway компилятор скажет, если забыл что-то определить.
Micktu 😬
мне ж главное чтобы он память контейнера не реаллоцировал
Micktu 😬
потому что поводов для этого как-то совсем нет
Micktu 😬
мне ж главное чтобы он память контейнера не реаллоцировал
т.е чтобы не случилось копирования, конечно
Surreal
А возможно запилить шаблон, который убирает у типа конструктор копирования?
Deleted Account
Surreal
Чтобы обвязку лишний раз не писать. Типа noncopy<std::map<int, int».
Nikita
А возможно запилить шаблон, который убирает у типа конструктор копирования?
boost::noncopyable
Deleted Account
просто отнаследуйся от когото у кого нет такого конструктара
Andrei
Лучше явно написать = delete;
Andrei
Какие прокси классы?
Andrei
О чем речь?
Andrei
struct Foo{
Foo(const Foo&) = delete;
}
Andrei
Всё! Ты создал некопируемую структуру.
Andrei
Зачем шаблоны, зачем наследоваться.
Andrei
Зачем писать в pro.cxx
Surreal
Вы меня не поняли. Допустим, есть куча объектов, у которых есть и copy и move конструкторы. Вдруг нам неожиданно хочется убрать у них copy конструктор и чего-нибудь с ними делать, а если делать неправильно, то у нас ошибка компиляции будет.
Surreal
Я концепты описал сейчас, походу.
Andrei
У существующего типа?
Surreal
Да.
Andrei
Невозможно. Практически невозможно.
Nikita