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

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

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

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

Часто программу оптимизируют больше, чем нужно. В узком месте обычно вычисления. В каких приложениях у тебя роль играет копирование иерархий массивов? Тут люди на Java пишут все вподряд, и не жалуются на скорость, а ты на С++ оптимизируешь какую-то мелочевку.

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

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

Использование move-семантики — это и есть эталонная экономия на спичках(копировании). Измерял профилировщиком выигрыш в скорости от мув-семантики где-нибудь, и вклад этого выигрыша в суммарное время отклика или скорость?

Я понимаю, что с точки зрения теории для языка программирование это интересная фича, которая иногда даже может пригодиться. Но это не значит что нужно тянуть ее в стандарт. Лучше оставить язык простым, без новых типов ссылок, и это будет удобно почти везде. А тем, кому все-же нужно оптимизровать копирование, нужно оставить возможность сделать это вручную.

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

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

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

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

Часто программу оптимизируют больше, чем нужно. В узком месте обычно вычисления. В каких приложениях у тебя роль играет копирование иерархий массивов, которое работает дольше логики? Тут люди на Java пишут все вподряд, и не жалуются на скорость, а ты на С++ оптимизируешь какую-то мелочевку.

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

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

Использование move-семантики — это и есть эталонная экономия на спичках(копировании). Измерял профилировщиком выигрыш в скорости от мув-семантики где-нибудь, и вклад этого выигрыша в суммарное время отклика или скорость?

Я понимаю, что с точки зрения теории для языка программирование это интересная фича, которая иногда даже может пригодиться. Но это не значит что нужно тянуть ее в стандарт. Лучше оставить язык простым, без новых типов ссылок, и это будет удобно почти везде. А тем, кому все-же нужно оптимизровать копирование, нужно оставить возможность сделать это вручную.