а что тогда вообще можно сделать?

https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/sdp/sipcc/sdp_token.c#87-90

вот такая проверка на стороне firefox

А библиотека, которая заполняет это поле, берет его из unsigned long long

static_cast -1 в unsigned это unspecified вроде

почему? https://en.cppreference.com/w/cpp/language/implicit_conversion это integer conversion в usigned -> по модулу 2^n завраппится

почему? https://en.cppreference.com/w/cpp/language/implicit_conversion это integer conversion в usigned -> по модулу 2^n завраппится

↑ This only applies if the arithmetic is two's complement which is only required for the exact-width integer types. Note, however, that at the moment all platforms with a C++ compiler use two's complement arithmetic

по стандарту это unspecified

но это же про sign-extended, нет? а предложение выше остается в силе даже не в two complement

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html плюс если говорить то вроде эту бумагу приняли

https://twitter.com/jfbastien/status/989242576598327296 ну ток в с++20 конечно да

А здесь не было фанатов undeclare operator? Который там forward делает и переменную разобъявляет? Видимо, перегрузка такого оператора (с запретом перемещения типа std::move) позволяет делать not nullable unique ptr

А здесь не было фанатов undeclare operator? Который там forward делает и переменную разобъявляет? Видимо, перегрузка такого оператора (с запретом перемещения типа std::move) позволяет делать not nullable unique ptr

Это как undeclare?

А здесь не было фанатов undeclare operator? Который там forward делает и переменную разобъявляет? Видимо, перегрузка такого оператора (с запретом перемещения типа std::move) позволяет делать not nullable unique ptr

А зачем?

А зачем?

Вот теперь есть аргумент зачем: это принципиально отдельный тип перемещения

Вот теперь есть аргумент зачем: это принципиально отдельный тип перемещения

А для чего он? И в чем его глубокий смысл?

А для чего он? И в чем его глубокий смысл?

Что значит вопрос "для чего"? Глубокий смысл "последнее использование переменной"

Что значит вопрос "для чего"? Глубокий смысл "последнее использование переменной"

"Для чего" то и означает: для чего он? Я правильно понял, что это, например, позволяет в compile time удостовериться, что к "moved out" переменной дальше нет обращений? Это все?

} // undeclare

А для чего он? И в чем его глубокий смысл?

Сделать move семантику как в Rust. После std::true_move переменную никак нельзя будт использовать, любая попытка к ней обратиться - будет ошибкой на этапе компиляции. Позволит например вот тут https://github.com/apolukhin/dmn/blob/master/src/impl/node_parts/write_n.hpp#L157-L160 лучше проверять на этапе компиляции и лучше переиспользовать компилятору стек

Надо тогда [[undeclare]]

И онли как хинт

Надо тогда [[undeclare]]

Атрибуты не должны влиять на компилируемость приложения

Атрибуты не должны влиять на компилируемость приложения

Зато можно кидать ворнинги

А здесь не было фанатов undeclare operator? Который там forward делает и переменную разобъявляет? Видимо, перегрузка такого оператора (с запретом перемещения типа std::move) позволяет делать not nullable unique ptr

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

Сделать move семантику как в Rust. После std::true_move переменную никак нельзя будт использовать, любая попытка к ней обратиться - будет ошибкой на этапе компиляции. Позволит например вот тут https://github.com/apolukhin/dmn/blob/master/src/impl/node_parts/write_n.hpp#L157-L160 лучше проверять на этапе компиляции и лучше переиспользовать компилятору стек

Вот есть мнение, что на самом деле есть move, есть forward и есть undeclare, который похож на forward, только чаще применим

Все равно старперам из компиляторов это не понравится делать

Все равно старперам из компиляторов это не понравится делать

Ну вообще-то они не прочь :)

Вот есть мнение, что на самом деле есть move, есть forward и есть undeclare, который похож на forward, только чаще применим

Яб назвал его transfer а не undeclare. Мы именно целиком передаём владение объектом

Сделать move семантику как в Rust. После std::true_move переменную никак нельзя будт использовать, любая попытка к ней обратиться - будет ошибкой на этапе компиляции. Позволит например вот тут https://github.com/apolukhin/dmn/blob/master/src/impl/node_parts/write_n.hpp#L157-L160 лучше проверять на этапе компиляции и лучше переиспользовать компилятору стек

Да! Нужно! Прям щас! (вот серьёзно.)

Яб назвал его transfer а не undeclare. Мы именно целиком передаём владение объектом

+

Где подписаться?

Где подписаться?

stdcpp.ru

Закиньте идею на stdcpp.ru Если готовы взяться - всячески помогу, но проработать краевые случаи и накидать черновик предложения - с вас

Особенно надо проработать ситуации void foo(something& v) { auto new_v = std::transfer(v); /*...*/ }

if(smth){ foo(transfer(bar)); } bar.smth(); Ожидаемое поведение какое?

if(smth){ foo(transfer(bar)); } bar.smth(); Ожидаемое поведение какое?

Ошибка компиляции.

Ошибка компиляции.

+1

Ошибка компиляции.

smth всегда фолсит

Не должно быть такого поведения.

Ну да наверн это правильно

Яб назвал его transfer а не undeclare. Мы именно целиком передаём владение объектом

Записал

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

teleport ?

не, телепорт предполагает что есть точка А и точка Б и мы передаем что-то между ними. А тут мы не просто передаем, а еще и точка А исчезает из бытия

Что-то типа replace_by хочется придумать, но у меня нет годных идей

Или rename

Что-то такое

gift()

Move!

!move!constexpr

А в комитете нет профессионального лингвиста? Чтобы придумывал названия

Го лучше оператор придумаем

Foo foo; bar($foo)

Класс

Типа продал

Так придумано уже всё

bar <- foo

украдем из R присваивание, чо

bar(<- foo);

auto$ bar=$foo;

Кстати FOO&& f=transfer(bar); bar.test(); Какое ожидаемое поведение?

ошибка компиляции же

нет?

squash еще интересное название, но мне тоже не нравится

А auto& bar2=bar; FOO&& f=transfer(bar); bar2.test(); ?

Тоже. Я так понимаю, что основная сложность - описать все вот подобные случаи.

И с указателями очевидно не будет работать без borrow checker

А если я внутрь класса ссылку сохраню?

Ну, т.е. Foo* x = &bar; Foo f = transfer(bar); *x; // UB

И вот такое всякое будет плохо получаться

Ну типа в таком контексте выглядит как кучка эвристик которые ничего толком не дают чуть глубже чем описано в бумаге

Трансфер вполне ок

Трансфер вполне ок

Букв же много

std::trans :)

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

steal? ;)

Имхо ваще перемещение первично а копирование вторично, к тому же чем дороже тем больше писать должно быть а не наоьорот

carry?

!move!constexpr

Ты слышал видать про constexpr!

Будем как кононичнве плюсачи

carry?

Mid. Не удержался

Мув не перемещает, карри не карирует

hide

Шутка про static который неявно extern

ship

Сокрытие переменной std::hide с передачей состояния

Это отражает то, что произойдет с переменной

Она перестанет быть доступной

force_hided_move

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

Ну Атону не понравился undeclare, а мне в ответ не понравился transfer... И тут всё как закрутилось

здесь надо что-то наукоемкое... что-то вроде аннигиляции