Здравствуйте, lpd, Вы писали:
_>>Естественно конструктор перемещение. Т.е. банально добавить в класс big_object метод "big_object(big_object&& о) {}" и всё, семантика перемещения заработает для данного классса. lpd>OK, move-конструктор. Тем не менее, я считаю, что с ними слишком запутанные правила. Я бы предпочел, чтобы по вызывающему коду было понятно, что тут move, и не требовалось каждый раз смотреть определение класса.
Ты сказал компилятору, что данный класс умеет перемещаться и соответственно компилятор будет вставлять эту оптимизацию везде, где только сможет. Плюс, в тех местах, где он сам не может, ты можешь ему указать это руками с помощью функции move.
_>>Ну так и какой код выглядит сложнее и объёмнее, мой или твой? ) Ты же заявлял, что код с применением семантики перемещения существенно усложняется... lpd>Более короткий код не значит простой, кроме того:
В данном случае он именно что более простой — имеет буквально такой же вид, какой был бы в случае int вместо big_object.
_>>Да, а семантика перемещения как раз полностью решает проблему с передачей этого "локального" объекта куда-то ещё. lpd>Как передать этот локальный объект в другой поток? он на стеке и может быть уничтожен, пока другой поток будет еще выполняться. С указателем это делается легко и непринужденно.
Организация многопоточной работы — это отдельная большая и сложная тема со многими вариантами решения. Но я могу тут сразу заметить, что семантика перемещения просто идеально ложится на одно из самых лучших решений в этой области под названием "модель акторов". )
_>>И именно такой подход существенно убивает производительность, т.к. добавляет лишний уровень косвенности. lpd>Ты что, всерьез заботишься о времени разыменования указателя? оно ничтожно, а в тех очень редких случаях, где играет роль, пишут просто вставки на ассемблере. Или как такой подход убивает производительность?
Дело не в разыменования указателя, а в технике работы кэща процессора. В случае обхода одного непрерывного массива данных у тебя все запрашиваемые данные будут уже в кэше, что ускорит работу в разы. А в случае использования массива указателей они практически наверняка (ну если ты там не используешь именно для этих данных какой-нибудь специальный аллокатор на пуле) будут указывать на различные непоследовательные участки памяти...
lpd>Большие объекты в векторе лучше не хранить из-за реаллокации при изменении размера и фрагментации после eraseов. Поэтому и в этом случае указатели удобнее.
При таких условиях задачи надо вообще использовать другой контейнер. )))
lpd>Так что все еще необходим пример(желательно конкретного приложения), в котором нужна move-семантика.
Что значит "нужна"? )
Вот есть у тебя некое красивое, но не идеально оптимизированное C++ приложение (встречаются копирования объектов и т.п.). Ты добавил в него поддержку семантики перемещения и получил ускорение его работы на сколько то там процентов при сохранение внешнего вида кода. Это как считается, "нужна" или нет? )
Или вот скажем у тебя есть хорошо оптимизированное приложение написанное на чистых указателях, где ты страдаешь с ручным отслеживанием всего этого дела. Ты переписал это всё на современном C++, сохранив старую производительность и при этом полностью забыл про все ужасы ручных указателей. Это считается "нужна" или нет? )
