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

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

lpd>>Реально мув-семантика играет сколько-то заметную роль в конечном общем быстродействии программы очень-очень редко
CC>Просто поменяй всё && на одинарный & и тут же начнётся веселуха, когда вместо того чтоб забрать объект в контейнер его сначала весь скопируют а потом старый убьют. И как только объект в себе тащит другие объекты начинается deep copy, которое занимает время.

Я это понимаю, но где это копирование реально занимает хотя бы 10% времени от работы программы, чтобы это было заметно? Ради чего вся эта синтаксическая возня с && и std::move? Ну можно сделать move в узком месте, но все равно там будет прямое управление памятью и обычные C-массивы, с которыми для этого одного объекта можно сделать мув вручную.

lpd>> и это не стоит реализации ее в C++ языке, тем более такой запутанной.
CC>А запутанность то там где?
Новый тип ссылок, move — там немало нового вроде как.

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

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

Это то же самое, только проще, и это нужно максимум для пары массивов во всей программе.
Также для особых оптимизаций можно сделать vector::push_back_movable(IMovable3 *obj), и все.

lpd>>Вообще, такие узкие места, если они встречаются, оптимизируют часто на ассемблере или как минимум, прямой работой с памятью, и пихать мув в язык это лишнее.
CC>Я уже давно избавился от асма во всех проектах. Начиная с С++11 на плюсах такие куски стало писать значительно удобнее а работает так же быстро. Ну и развитие интринсиков также помогает.

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

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

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

lpd>>Реально мув-семантика играет сколько-то заметную роль в конечном общем быстродействии программы очень-очень редко
CC>Просто поменяй всё && на одинарный & и тут же начнётся веселуха, когда вместо того чтоб забрать объект в контейнер его сначала весь скопируют а потом старый убьют. И как только объект в себе тащит другие объекты начинается deep copy, которое занимает время.

Я это понимаю, но где это копирование реально занимает хотя бы 10% времени от работы программы, чтобы это было заметно? Ради чего вся эта синтаксическая возня с && и std::move? Ну можно сделать move в узком месте, но все равно там будет прямое управление памятью и обычные C-массивы, с которыми для этого одного объекта можно сделать мув вручную.

lpd>> и это не стоит реализации ее в C++ языке, тем более такой запутанной.
CC>А запутанность то там где?
Целый новый тип ссылок, move — там немало нового вроде как.

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

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

Это то же самое, только проще, и это нужно максимум для пары массивов во всей программе.
Также для особых оптимизаций можно сделать vector::push_back_movable(IMovable3 *obj), и все.

lpd>>Вообще, такие узкие места, если они встречаются, оптимизируют часто на ассемблере или как минимум, прямой работой с памятью, и пихать мув в язык это лишнее.
CC>Я уже давно избавился от асма во всех проектах. Начиная с С++11 на плюсах такие куски стало писать значительно удобнее а работает так же быстро. Ну и развитие интринсиков также помогает.

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