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

Вы не то проверяете.. Вы проверяете физическую сущность объекта, а 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, я не говорил что код переносится. я лишь пытался прояснить это: