итак. что же такое r-value refs & move-semantics?

что мне известно об этом?: первое(и вроде как единственное) - позволяет получать ссылки на временные объекты.


такой еще пример:

http://en.cppreference.com/w/cpp/utility/move

не может быть чтоб на этом польза от r-value refs & move-semantics закончилась.
поделитесь опытом, мыслями.

спасибо.

boostcoder

Это перемещение объекта, объект может быть не копируемым, но перемещаемым. В некоторых случаях копирование объекта невозможно реализовать, зато запросто можно реализовать перемещение.
Например класс std::unique_ptr не поддерживает копирование. Он не считает количество ссылок, т.е. его копирование просто невозможно (или он должен работать как auto_ptr), зато реализовано перемещение этого объекта, что позволяет хранить std::unique_ptr в контейнерах.

azesmcar, но у перемещаемого объекта все равно вызывается деструктор? и если да, то что он разрушает, если данные были перемещены?

Например:

http://liveworkspace.org/code/4baf51d7d55a...835aad73d11a085

Объект перемещается, т.е. все данные переместились в другой объект, в данном случае деструктор сделает delete 0 и успокоится.
Что делает деструктор и конструктор перемещения решает программист.

что-то не понял...
вот к примеру:

т.е. async_call() возвращает управление тут же. но если функциональный объект так же, тут же будет разрушен, то когда придет время его вызвать получим ошибку сегментации. или как?

Добавлено через 1 минуту и 53 секунды

ага. т.е. реализация деструктора должна предполагать подобное поведение?

Функциональный разрушен не будет, функциональный объект был перемещен и будет разрушен после выхода из области видимости.

Добавлено через 1 минуту и 57 секунд

точнее реализациа конструктора перемещения  
деструктор в моем примере ведет себя как обычно.

Извините что вмешиваюсь, вот по этой ссылке идет вроде не плохое и достаточно подробное объяснение r-value refs & move-semantics. 

Ну и к одному из приведенному примеру дается такое объяснение: " Instead of dynamically allocating memory, the move constructor and move assignment operator simply steal it from other .  When stealing, we copy other's pointer and then null it out.  When other is destroyed, its destructor will do nothing.". 

Там есть примеры показывающие различное поведение r-value refs, а также обсуждается как работает std::move() для различных аргументов:



Это сообщение отредактировал(а) rumit7 - 9.11.2011, 10:22

все равно не понимаю...

к примеру, r-value refs у нас нет. тогда мой пример записывался бы так:

т.е. тут создавался бы временный объект, внутри функции async_call() инициализировался бы другой объект, и временный объект бы разрушался. тут все понятно.

а вот с r-value что-то не понимаю смысла, если временный объект все равно создается и разрушается..

Добавлено через 1 минуту и 42 секунды
rumit7, спасибо. сейчас прочту.

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

Это сообщение отредактировал(а) azesmcar - 9.11.2011, 10:21

ааа! вот оно как.


  


вроде понял.. нужно усвоить.

azesmcar, все, понял. спасибо.

зы
с двухсотым плюсиком тебя.

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



польза например наблюдается при возвращении массива из функции.. 
если передачу в функцию еще как то могли смягчить за счет пристыковывания к константной ссылке, то с возвращением временого содержимого руки были связаны.. 

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

  да-да, типа того



boostcoder видимо имеет в виду это:
http://liveworkspace.org/code/1a70c160da7c...2dbaf2a272a94a2
хотя имхо польза от этого довольно сомнительная...

тоже вариант.

Экспериментировал как-то с move-semantics:
http://liveworkspace.org/code/ad3e28d4a554...cdfe13a7b58d551
Почему-то у меня упорно не хочет вызыватся move-ctor Str( Str && other );
Что я не так делаю...
И ещё. Там создаётся 4 объекта (x, y, x и result внутри operator+), а вызывается 3 деструктора. Как это ?
И где вызвался конструктор z ?

компилятор позволяет себе не переносить из временого в целевой, а сразу использовать целевой объект для результата..
если нужно задействовать именно move -семантику в вашем случае, укажите это с помощью move();

Добавлено через 1 минуту и 20 секунд

это по старым правилам 

там всего три объекта, погляди на адреса. result и z одно и то же.

что бы он вызвался, укажи семантику явно 


Добавлено через 4 минуты и 18 секунд

это NRVO отработало. велик могучий языка...

Добавлено через 6 минут и 1 секунду
оказывается уже ответили((

mes, baldina, спасибо за ответы, но
1) я хочу, чтобы move-конструктор вызывался автоматически, поэтому не хочу использовать std::move()
2) boostcoder говорит, что на LWS оптимизация выключена, а вы говорите, что


или это не имеет отношения к оптимизации ?
тогда вопрос снят

не имеет, это не оптимизация, а перенос при инициализации.. 

некий аналог этому из недалекого прошлого :

так же создается только один объект..


делайте перенос не при инициализации, а при присвоении..

Это сообщение отредактировал(а) mes - 9.11.2011, 19:46

Это получается как только я вызвал move constructor я уже объектом больше пользоваться не могу потому что данные были перемещены? Разве это не ведёт к понтенциальным ошибкам? Т.е. я должен теперь "запомнить", что объект был перемещён и больше его не трогать.

угу.


move-semantic довольно редко используется, в особых случаях. или же с временными объектами.
посему, потенциально не сильно увеличивает вероятность ошибок.

Это сообщение отредактировал(а) boostcoder - 5.3.2012, 16:15

объект, который подпадает под rvlaue-reference по любому ты использовать больше не сможешь. В простом случае, это правая часть выражения: a = c + b. Ты по любому после присваивания не сможешь воспользоваться временным объектом.
А если у тебя остаются возможности им воспользоваться, то он не является rvalue и, соответственно, не подпадает под действие перемещающего конструктора.

Можно ли пользоваться исходным объектом (откуда перемещали) после его перемещения?

http://liveworkspace.org/code/3c9358e9ddae...fd6df109b6ea1cd

нельзя


Логика проверки существования значения, путем вывода его в корне не верна.. 

кстати да.
но...раз объекта не существует, то при вызове X::print() разве не должен произойти сегфолт? или разница в том что X::print() это код, а X::data - данные? ведь по логике, код мы перемещать не можем.
так?

Я предполагал segfault, именно это я проверял, а не вывод и его значение.

Добавлено через 38 секунд

Проверял и с данными, сегфолта нет.

объект  (this) существует .. move не трогает сами объекты, а переносит их содержимое 

кстати в приведенном последнем примере, print демонстриует состояние, а не использует его.. так что по сути все правильно работает 

Я это и предполагал, хотел просто услышать материальное объяснение. 

потому что ваш move-ctor обнуляет указатель на данные, и следовательно состояние объекта корректно..

http://liveworkspace.org/code/c581e966af26...b39b963508fd5e4


Это сообщение отредактировал(а) Sahab - 13.4.2012, 20:30

состояние объекта после переноса неопределено.. 

Вы не то проверяете.. Вы проверяете физическую сущность объекта, а move изменяет состояние..

Добавлено через 1 минуту и 9 секунд
Sahab, в Вашем случае коректно.. но такое поведение не гарантированно, а следовательно может быть и подругому .. 

что я понял: move перемещает данные объекта, а следовательно - состояние.
то, что после перемещения, вызов X::print() не вызывает сегфолт - говорит лишь о том, что код не перемещается. оно и логично.
при чтении X::data сегфолт не происходит потому, что X::data после перемещения все равно на что-то указывает. на мусор на стеке, к примеру.

код никода не перемещается.. сегфолт происходит не из за какого то перемещения кода.. 
а из за за доступа к данным за пределами разрешений.. 

я же так и написал.

Добавлено через 4 минуты и 30 секунд
ну...почти так 

может быть.. я не понял при чем во фразе "код", поэтому и уточнил.. 

ну как же.. вызов функции это: 1)сохранение стека, 2)call, и т.д..
т.е. если бы перемещение так же бы и переносило и код вызова, то тогда бы точно получали сегфолт.

этим я всего лишь хотел сказать то, что успешный вызов X::print() без сегфолта - не показатель того что объект небыл перемещен. собственно, как и чтение переменной в которой до перемещения располагались данные.

 , ну пусть так.. тогда вопрос .. а если не переносит код ,то сегфолт невозможен ?!

возможен. но прежде чем получить сегфолт при доступе к "висячим" данным, нужно произвести вызов X::print(). я же об этом и говорил. а т.к. код не переносится, то и при перенесенном объекте вызов всегда будет успешным. а вот получим ли мы сегфолт при чтении данных - это уже другой вопрос.

Что вы тут спорите? move-семантика нужна в таких случаях, когда именно перемещение и необходимо. Для простых POD типов она смысла не имеет. А вот для контейнеров самое то. Потому что контейнер содержит несколько указателей. move-конструктор (например) копирует ЗНАЧЕНИЯ этих указателей в новый объект, а в старом (который передается как rvalue) их зануляет. Таким образом, деструктор старого объекта ничего не освободит, и новый объект будет существовать как ни в чем ни бывало. Это просто более быстрый вариант по сравнению с shared_ptr/array при использовании в таких ситуациях.

boostcoder, код вообще никогда не переносился, не переносится, и не будет переносится. 
Он один для всех объектов. 
Перенесение кода это не С++, более того, я даже не знаю, есть ли вообще в природе язык, где код переносится с экземпляром объекта.

это не от языка зависит. А от программиста. Если очень захотеть, то можно это сделать. По крайней мере на платформах, где нет защиты от выполнения кода в области данных.

bsa, я имел ввиду объекто-ориентированный аспект.
само перенесение кода, конечно возможно (хотябы в обычных exe-упаковщиках)
Это другое.

volatile, я не говорил что код переносится. я лишь пытался прояснить это:

boostcoder, исходным объектом пользоваться можно! Более того, исходный объект после перемещения используется как минимум в деструкторе. Но так как ты перенес состояние, то деструктор отработает "вхолостую" без реального освобождения ресурсов. А вот после деструктора объект уже использовать, как ты понимаешь, нельзя. По логике вещей, деструктор вызывается сразу же после отработки операции перемещения:Сначала выполнится y+z и результат поместится во временный объект. Затем вызовется перемещающий конструктор для x и перенесет состояние из временного объекта. Затем будет вызван деструктор временного объекта.

что значит можно ? да, он существуетн ( и довольно долго  если был не временным), но у него неопределено состояние, и соответсвенно, неопределено поведение..
для конкретного случая можно определить возможность использования, можно даже обратно вдохнуть жизнь в такие объекты, но нет возможности распространнить это на все случаи.. поэтому говорить о можно нельзя 
или иногда можно, но очень осторожно 



Это сообщение отредактировал(а) mes - 14.4.2012, 11:43

с чего это вдруг? у него вполне определенное состояние - то, в котором его оставил "перемещатель" (например, если перемещатель занулил только указатель на начало данных вектора, а остальные оставил без изменений, то состояние неопределенное - в общем случае, только деструктор отработает корректно). А это уже задача программиста следить за тем, чтобы состояние соответствовало планам использования.
Имхо, после перемещения объект должен быть уничтожен... А "вдыхать" в него жизнь - это только делать себе хуже.

это то понятно.. но во первых нет гарантий заставляющих оставлять объект в коректном состоянии, во вторых нет (не всегда есть) такой возможности.. 

 а для общего случая нельзя.. 

йопт... так можно или нельзя?
Че в стандарте написано?

имелось ввиду не состояние конкретного объекта, а состояние любого объекта после перемещения..

Добавлено @ 12:20

вообще применять move семантику нужно к rvalue...
но С++, как говорится, всегда готов придти на помощь, и можно применить move для lvalue,  однако в этом случае ответственность ложится на плечи программиста, а стандарт умывает руки   

Это сообщение отредактировал(а) mes - 14.4.2012, 13:49

Классно сказано! Ёмко!