А чем undeclare не понравился то? я не понял

видишь, все кроме transfer не несут смысловую нагрузку по перемещению состояния

по идее, надо так и называть transfer_and_undeclare

но это чертовски длинно

А как переселение душ по англ? transmigrate?

Как-то так?

Переселение душ это не то.

можно короче: eat

Тело-то тоже перемещается.

лучше std::omnomnom тогда

eat неплохо, да

eat наверное отражает действие, которое совершается с объектом

объект уходит, а состояние попадает в пищевод

Мне нравится, да

Мне нравится омномном

А, теперь понял, все хотят fun(transfer(x)) а не fun(move(x)); undeclare x; Соглашусь, да

мимокрокодил, это какая-то новая фича? пропозал?

мимокрокодил, это какая-то новая фича? пропозал?

пока фантазии

ИМХО, transfer вполне хорошо смотрится всё же.

Как-то что-то другое даже не придумывается...

drag ?

haul

ИМХО, transfer вполне хорошо смотрится всё же.

да, он смотрится годно, но не совсем точно говорит о том, что же ждет переменную

хотя, с другой стороны, уже сказано либо писать толстовские фразы transfer_and_undeclare, либо как-то так std::transfer/std::eat

drag ?

Кстати drop

нуль телепортация

Сепуление, ага

Marshall

rlymove

да, он смотрится годно, но не совсем точно говорит о том, что же ждет переменную

Ну, не беда... Уже есть move...

Pass

А зачем давать имя? Ведь если реализовать фичу из раста, то и работать это должно глобально. Ну да, старый код малеха сломается. В противном случае весь код заполнится transfed(x) + можно будет забыть написать. Двойная работа.

+1

Т.е. безусловно, если хоть где-нибудь встретилось borrow то независимо от условия значение считается borrowed?

Да

Хм... std::borrow

Хм... std::borrow

?

Чем отличается T& от T&&

?

какой контекст

тут это важно

потомучто int&& это rvalue reference а template<typename T> void foo(T&&) - forwarding reference

какой контекст

Не использовал, не знаю, хочу разобраться

Про ссылку я знаю, ссылка это ссылка, а вот как работает && недогоняю

Про ссылку я знаю, ссылка это ссылка, а вот как работает && недогоняю

Если в темплейтах, то форвардится либо reference or rvalue-reference, зависит от того что ты вкинул в темплейт параметр, если это не в контексте темплейтов то это rvalue-reference

Чем отличается T& от T&&

что уже читал? что понял?

Чем отличается T& от T&&

Ну а вообще, для такого @supapro

что уже читал? что понял?

Про то, что & это lvalue, а && rvalue. Но в чем между ними разница, в каких случаях используется & , а в каких &&

Не использовал, не знаю, хочу разобраться

иди читай майерса

иди читай майерса

Теперь нужно аккуратно читать. Скотт сказал что больше не будет править найденные косяки в книгах

про forwarding reference там без ошибок ?

Теперь нужно аккуратно читать. Скотт сказал что больше не будет править найденные косяки в книгах

Конечно теперь опаснее читать, ведь ошибки в книге про C++11 будут встречаться чаще чем раньше. Осталось только понять почему. Потому что C++11 все еще допиливают или что?

про forwarding reference там без ошибок ?

там ваще в названии ошибка

там ваще в названии ошибка

там есть про эта пометка, я читал с пометкой уже, что книгу до названия forwarding reference написао Скотт

Конечно теперь опаснее читать, ведь ошибки в книге про C++11 будут встречаться чаще чем раньше. Осталось только понять почему. Потому что C++11 все еще допиливают или что?

JFYI, если искать лениво: http://www.aristeia.com/BookErrata/ec++3e-errata.html и http://www.aristeia.com/BookErrata/emc++-errata.html Обрати внимание, когда вышла книга, и сколько еще времени слали найденные баги

И до сих пор, кстати, шлют

JFYI, если искать лениво: http://www.aristeia.com/BookErrata/ec++3e-errata.html и http://www.aristeia.com/BookErrata/emc++-errata.html Обрати внимание, когда вышла книга, и сколько еще времени слали найденные баги

Ну теперь багов в книжке прибавится? Логика подсказывает что их останется не больше чем было раньше.

О них теперь не будет известно. Скотт не будет проверять и публиковать исправления, и даже сообщать о найденных кем-то ошибках.

Но конечно это не помешает писать код в стиле "скомпилил-поправил ошибку-скомпилил-поправил ошибку-повторить 100500 раз"

Ну а вообще, для такого @supapro

Не совсем, это сложный, тяжёлый вопрос...

Про то, что & это lvalue, а && rvalue. Но в чем между ними разница, в каких случаях используется & , а в каких &&

Это не так. Обе ссылки могут быть на любые значения. Ты уже запутался.

Ну а вообще, для такого @supapro

Крисс, у тебя не осталось статьи что я тебе давал по универсальным ссылкам? Дай парню если есть ...

У меня просто не под рукой.

Это просто ещё одна статья с объяснением универсальных ссылок, мне например зашла лучше Меерса

Го сюда ее

Хм... std::borrow

Не, всё таки borrow подразумевает возврат владения.

Не, всё таки borrow подразумевает возврат владения.

И не std, это же не библиотечная явно фича.

И не std, это же не библиотечная явно фича.

Какой нибудь префиксный оператор, типа ->. Foo(->x).

Какой нибудь префиксный оператор, типа ->. Foo(->x).

Это получается cast в rvalue и вызов деструктора в конце текущего выражения. А значит деструктор на выходе из scope будет условный.

Это получается cast в rvalue и вызов деструктора в конце текущего выражения. А значит деструктор на выходе из scope будет условный.

Значит переменная будет сопровождаться флагом moved и обращение после перемещения может быть compile error в том же scope и runtime error за его пределами.

Крисс, у тебя не осталось статьи что я тебе давал по универсальным ссылкам? Дай парню если есть ...

Сейчас не смогу найти

можно короче: eat

можно длиннее, но, imo, понятнее: reloc

reloc тоже перемещение, но предполагает, что на старом месте работника уже нет.

а вот как runtime error делать, не вкурю. объекта то уже нет, кто будет хранить инфу о том, что он уже "всё". замусорить память?

reloc тоже перемещение, но предполагает, что на старом месте работника уже нет.

Подразумевает, что старое место есть

Чем отличается T& от T&&

Читай тут http://thbecker.net/articles/rvalue_references/section_01.html

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

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

А что вотэто был за поток сознания про какие-то перемещения? Можно резюме, ибо я лично ничего не понял.

тут подумав добавить проверку к своему проекту что отправил по usb контрольную сумму сравнить. Пока не смотрел как делать, есть у вас предложение как это реализовать?

Значит переменная будет сопровождаться флагом moved и обращение после перемещения может быть compile error в том же scope и runtime error за его пределами.

Не, это всё не будет работать, уже есть move-семантика на которой всё это можно сделать. Нужно чтобы в компайл-тайме компилятор ругался на использование имени уничтоженной переменной.

А что вотэто был за поток сознания про какие-то перемещения? Можно резюме, ибо я лично ничего не понял.

это я про вчерашнее, около 21 часа обсуждение undeclare-transfer.

тут подумав добавить проверку к своему проекту что отправил по usb контрольную сумму сравнить. Пока не смотрел как делать, есть у вас предложение как это реализовать?

В USB же внутри уже есть контроль данных

тут подумав добавить проверку к своему проекту что отправил по usb контрольную сумму сравнить. Пока не смотрел как делать, есть у вас предложение как это реализовать?

Почситать. ПОслать. посчитать на приёмном конце. Сравнить.

это я про вчерашнее, около 21 часа обсуждение undeclare-transfer.

А вот undeclare это как ?

тут подумав добавить проверку к своему проекту что отправил по usb контрольную сумму сравнить. Пока не смотрел как делать, есть у вас предложение как это реализовать?

я только проснулся и сейчас пришла это идея =)

В USB же внутри уже есть контроль данных

хорошо

Значит переменная будет сопровождаться флагом moved и обращение после перемещения может быть compile error в том же scope и runtime error за его пределами.

Фактически, изначальное предложение (как понял его я) - это механизм, аналогичный концу скоупа }, но действующий изберательно на определенную переменную. Но дальше чтобы каждый раз не писать y = std::move(x); undeclare x; предлагается объединить это в одну операцию (оператор), который стирает из бытия компайл-тайма переменную, но позволяет забрать из неё состояние перед этим (на случай, если оно кому-то нужно).

а вот как runtime error делать, не вкурю. объекта то уже нет, кто будет хранить инфу о том, что он уже "всё". замусорить память?

Компилятор скрытый флаг сделает. А вот runtime error какой это да, непонятно, UB или сигнал какой то по аналогии с segfault.

Фактически, изначальное предложение (как понял его я) - это механизм, аналогичный концу скоупа }, но действующий изберательно на определенную переменную. Но дальше чтобы каждый раз не писать y = std::move(x); undeclare x; предлагается объединить это в одну операцию (оператор), который стирает из бытия компайл-тайма переменную, но позволяет забрать из неё состояние перед этим (на случай, если оно кому-то нужно).

А нафига такое надо вообще? Ни в одном языке которые я знаю, нет такой возможности. Как-то это намекает на то, что такая возможность не нужна никому.

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

А нафига такое надо вообще? Ни в одном языке которые я знаю, нет такой возможности. Как-то это намекает на то, что такая возможность не нужна никому.

Говорят есть в расте

А нафига такое надо вообще? Ни в одном языке которые я знаю, нет такой возможности. Как-то это намекает на то, что такая возможность не нужна никому.

Например, чтобы компилятор ловил ошибки за программистом, который смувил переменную, а потом в неё полез случайно (потому-что опечатлося к примеру) и обнаружил это только в рантайме по странным глюкам

Например, чтобы компилятор ловил ошибки за программистом, который смувил переменную, а потом в неё полез случайно (потому-что опечатлося к примеру) и обнаружил это только в рантайме по странным глюкам

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