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

lpd>Я это понимаю, но где это копирование реально занимает хотя бы 10% времени от работы программы, чтобы это было заметно?
Достаточно чтоб оно занимало слишком много времени в узком месте.

lpd> Ради чего вся эта синтаксическая возня с && и std::move?
lpd> Ну можно сделать move в узком месте, но все равно там будет прямое управление памятью и обычные C-массивы
А массивы то откуда взялись? И зачем для move "прямое управление памятью"?

lpd>Целый новый тип ссылок, move — там немало нового вроде как.
Совсем чуть чуть: новый тип с довольно ограниченным применением и пучок правил как оно работает.

lpd>>> Там где это нужно, можно сделать у объекта руками метод Move(), в том числе для push_back().
CC>>Всё можно сделать на ручнике, только вот беда в том что кода зело много приходится писать.
lpd>Почему много? У тебя есть CCString{ char *buf }; Вместо std::move для этого класса можно сделать метод:
lpd>

lpd>CCString::Move(CCString *str1) 
lpd>{
    this->>buf = str1->buf;
    str1->>buf=0;
lpd>}
lpd>

lpd>Это то же самое, только проще

Как с таким подходом задать move constructor рядом с copy constructor?
Самый большой impact от разницы move vs copy+delete получается когда ты не простой объект пихаешь а составной, внутри которого большая иерархия.
Это всё можно сделать и на ручнике, но с move constructor это всё работает автоматически.

lpd> и это нужно максимум для пары массивов во всей программе.
Да как то в гораздо большем колве мест на деле.

lpd>Я вообще не сторонник лишних оптимизаций, но в крайнем случае предпочту прямую работу с памятью, чем расчет на магию компилятора.

Я уже давно убедился что современный промышленный компилятор генерит достаточно хороший код чтоб перестать экономить на спичках и забил на заморочки. Профайлером поглядываю на критические куски иногда и пока всё хорошо. Уже давно всё упирается скорее в data layout (cache hit/miss) чем в инструкции. А SSE оптимизации на интринсиках удобно вышиваются.