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

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

lpd>>Как передать этот локальный объект в другой поток? он на стеке и может быть уничтожен, пока другой поток будет еще выполняться. С указателем это делается легко и непринужденно.

_>Организация многопоточной работы — это отдельная большая и сложная тема со многими вариантами решения. Но я могу тут сразу заметить, что семантика перемещения просто идеально ложится на одно из самых лучших решений в этой области под названием "модель акторов". )

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

_>>>И именно такой подход существенно убивает производительность, т.к. добавляет лишний уровень косвенности.
lpd>>Ты что, всерьез заботишься о времени разыменования указателя? оно ничтожно, а в тех очень редких случаях, где играет роль, пишут просто вставки на ассемблере. Или как такой подход убивает производительность?

_>Дело не в разыменования указателя, а в технике работы кэща процессора. В случае обхода одного непрерывного массива данных у тебя все запрашиваемые данные будут уже в кэше, что ускорит работу в разы. А в случае использования массива указателей они практически наверняка (ну если ты там не используешь именно для этих данных какой-нибудь специальный аллокатор на пуле) будут указывать на различные непоследовательные участки памяти...

Это при условии, что контейнер, все-таки вектор, да еще и обходится последовательно, что не столь типично.

_>Вот есть у тебя некое красивое, но не идеально оптимизированное C++ приложение (встречаются копирования объектов и т.п.). Ты добавил в него поддержку семантики перемещения и получил ускорение его работы на сколько то там процентов при сохранение внешнего вида кода. Это как считается, "нужна" или нет? )
Если нужно ускорение работы на несколько процентов, то я бы использовал ассемблер.

_>Или вот скажем у тебя есть хорошо оптимизированное приложение написанное на чистых указателях, где ты страдаешь с ручным отслеживанием всего этого дела. Ты переписал это всё на современном C++, сохранив старую производительность и при этом полностью забыл про все ужасы ручных указателей. Это считается "нужна" или нет? )
Ручные указатели ужасом мне не представляются, в отличие от всего свода правил по rvalue-ссылкам.

В принципе, если кто-то действительно может быстрый и понятный(хотя бы ему) код с move-семантикаой, то это само по себе не плохо. Кому-то вот, например нравится ассемблер, и он будет писать код, который ему нравится со вставками на ассемблере. Другой добавит туда perl6, который ему нравится. Я к тому, что случается решение о принятии move-семантике может принима

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

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

lpd>>Как передать этот локальный объект в другой поток? он на стеке и может быть уничтожен, пока другой поток будет еще выполняться. С указателем это делается легко и непринужденно.

_>Организация многопоточной работы — это отдельная большая и сложная тема со многими вариантами решения. Но я могу тут сразу заметить, что семантика перемещения просто идеально ложится на одно из самых лучших решений в этой области под названием "модель акторов". )

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

_>>>И именно такой подход существенно убивает производительность, т.к. добавляет лишний уровень косвенности.
lpd>>Ты что, всерьез заботишься о времени разыменования указателя? оно ничтожно, а в тех очень редких случаях, где играет роль, пишут просто вставки на ассемблере. Или как такой подход убивает производительность?

_>Дело не в разыменования указателя, а в технике работы кэща процессора. В случае обхода одного непрерывного массива данных у тебя все запрашиваемые данные будут уже в кэше, что ускорит работу в разы. А в случае использования массива указателей они практически наверняка (ну если ты там не используешь именно для этих данных какой-нибудь специальный аллокатор на пуле) будут указывать на различные непоследовательные участки памяти...

Это при условии, что контейнер, все-таки вектор, да еще и обходится последовательно, что не столь типично.

_>Вот есть у тебя некое красивое, но не идеально оптимизированное C++ приложение (встречаются копирования объектов и т.п.). Ты добавил в него поддержку семантики перемещения и получил ускорение его работы на сколько то там процентов при сохранение внешнего вида кода. Это как считается, "нужна" или нет? )
Если нужно ускорение работы на несколько процентов, то я бы использовал ассемблер.

_>Или вот скажем у тебя есть хорошо оптимизированное приложение написанное на чистых указателях, где ты страдаешь с ручным отслеживанием всего этого дела. Ты переписал это всё на современном C++, сохранив старую производительность и при этом полностью забыл про все ужасы ручных указателей. Это считается "нужна" или нет? )
Ручные указатели ужасом мне не представляются, в отличие от всего свода правил по rvalue-ссылкам.

В принципе, если кто-то действительно может быстрый и понятный(хотя бы ему) код с move-семантикаой, то это само по себе не плохо. Кому-то вот, например нравится ассемблер, и он будет писать код, который ему нравится со вставками на ассемблере. Другой добавит туда perl6, который ему нравится.
Я к тому, что главное не использовать move-семантику только потому, что она в новом стандарте, а значит, типа, must-have.

Я еще редактировал предыдущий пост недавно, и добавлял:
На мой взгляд — обычный C++ это баланс производительностью, удобством и простотой, с возможностью ручного ассемблера. А с move-семантикой теряется простота. Кроме того, вот я когда то достаточно написал программ на ассемблере, и мне с моим опытом не очевидно, как move-семантика реализована. Компилятор резервирует место на стеке, выходит из функции, а когда стек возвращается к передвинутой локальной переменной, пропускает этот кусок памяти? или как?