foo(->x); use(x); // compile error, x not defined if(condition) foo (->y); use(y); // UB if condition

господа, меня тут чуть-чуть перемкнуло - класть -1 в uin64_t это же numeric_limits<uint64_t>::max, а не UB которое по счастливому стечению все компиляторы реализуют одинаково?

господа, меня тут чуть-чуть перемкнуло - класть -1 в uin64_t это же numeric_limits<uint64_t>::max, а не UB которое по счастливому стечению все компиляторы реализуют одинаково?

это точно не UB, максимум unspecified, но там врап относительно 2^n, так что должно быть max

господа, меня тут чуть-чуть перемкнуло - класть -1 в uin64_t это же numeric_limits<uint64_t>::max, а не UB которое по счастливому стечению все компиляторы реализуют одинаково?

Нет, unsigned int overflow - это defined behavior исторически

Из-за программирования микроконтроллеров

Так можно короч

> unsigned int overflow тьфу чёрт, вот как это называлось, а я загуглить не мог нормально) только underflow, порядка ради спасибо

ток это не overflow, а conversion

нет?

> The correct reference is §6.3.1.3 (signed and unsigned integer conversion) даже conversion, да

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

ток это не overflow, а conversion

Да и оно valid and well-defined.

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

начал смотреть my little pony @ выучил английский лучше чем в школе учили #offtop #holywar @fludpac https://telegram.me/joinchat/Be4rsT4dVSVwtOB3vmuD7Q

господа, меня тут чуть-чуть перемкнуло - класть -1 в uin64_t это же numeric_limits<uint64_t>::max, а не UB которое по счастливому стечению все компиляторы реализуют одинаково?

Забавно, что для знаковых переполнение ub

Но так исторически сложилось, и с этим и живём

да-да, про знаковые я помнил, и про переполнение вида unsigned x = UINT_MAX; ++x; я тоже помнил, а вот про инициализацию -1 что-то заклинило

Я даже вспомнил когда про такое узнал и запомнил https://events.yandex.ru/lib/talks/4273/ Спасибо РГ21 за приглашение Marshall Clow, было круто.

foo(->x); use(x); // compile error, x not defined if(condition) foo (->y); use(y); // UB if condition

Иф должен тоже давать компиль еггор

Не хочешь еггор юзай move

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

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

да, вот ребята хотять избежать использования в невалидном состоянии путем замены милосердного move на убийственное transfer

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

move вообще не для этого, ты в 90% не будешь иметь доступ к переменной - источнику вообще, потому что она была временной. Так что такая фича не нужна вообще.

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

Можно сделать. Но частый паттерн использования состоит в том, что забыть про неё. И в таком случае попытка залезть в переменную без её новой инциализации является ошибкой

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

Детский сад какой-то, типа "придёт бабайка, и утащит всех нас"...

Детский сад какой-то, типа "придёт бабайка, и утащит всех нас"...

Бабайки не существует.

Детский сад какой-то, типа "придёт бабайка, и утащит всех нас"...

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

Ну умные указатели решают проблему неопределённого времени жизни объекта.

Ну умные указатели решают проблему неопределённого времени жизни объекта.

Бабайки не существует.

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

Тут сложный момент. Если делать это не библиотекчным решением, то это должно быть что-то, что не пересекается с имеющимися пользовательскими функциями. Тоесть сделать borrow(x) - нельзя, у пользователей может быть функция borrow, а мы её таким образом сломаем. можно сделать auto y = borrow x; но надо продумать граничные случаи. Так например, хотим ли мы позволять делать borrow x; без захвата возращённого значения? Если да - то будут проблемы с тем, что у пользователя может быть класс borrow

Тут сложный момент. Если делать это не библиотекчным решением, то это должно быть что-то, что не пересекается с имеющимися пользовательскими функциями. Тоесть сделать borrow(x) - нельзя, у пользователей может быть функция borrow, а мы её таким образом сломаем. можно сделать auto y = borrow x; но надо продумать граничные случаи. Так например, хотим ли мы позволять делать borrow x; без захвата возращённого значения? Если да - то будут проблемы с тем, что у пользователя может быть класс borrow

Я говорил уже, чтобы без конфликтов, может новый оператор? Как spaceship добавили, например префиксный "->".

Я говорил уже, чтобы без конфликтов, может новый оператор? Как spaceship добавили, например префиксный "->".

Новый оператор - это очень неудобно, скатываемся в перл. Вот представьте, что вы плохо знаете C++, читаете чужой код и видите конструкцию auto [a, b] = foo();. теперь попробуйте найти в поисковике описание этой конструкции не используя слова structured binding.

Новый оператор - это очень неудобно, скатываемся в перл. Вот представьте, что вы плохо знаете C++, читаете чужой код и видите конструкцию auto [a, b] = foo();. теперь попробуйте найти в поисковике описание этой конструкции не используя слова structured binding.

google и правда не находит, а вот яндекс выдаёт в первой же ссылке

google и правда не находит, а вот яндекс выдаёт в первой же ссылке

поправим пример, чтобы он был больше похож на реальный код auto [ok, it] = qwe.insert(data); https://yandex.ru/search/?text=auto%20%5Bok%2C%20it%5D%20%3D%20qwe.insert(data)%3B И получается совсем плохо

Did you mean: auto [ok, if] = we.insert(data);

поправим пример, чтобы он был больше похож на реальный код auto [ok, it] = qwe.insert(data); https://yandex.ru/search/?text=auto%20%5Bok%2C%20it%5D%20%3D%20qwe.insert(data)%3B И получается совсем плохо

Увы, да.

поправим пример, чтобы он был больше похож на реальный код auto [ok, it] = qwe.insert(data); https://yandex.ru/search/?text=auto%20%5Bok%2C%20it%5D%20%3D%20qwe.insert(data)%3B И получается совсем плохо

https://www.google.com/search?q=auto+square+brackets+assignment+c%2B%2B&newwindow=1&client=firefox-b&oq=auto+square+brackets+assignment+c%2B%2B&gs_l=mobile-heirloom-serp.3...12662.14067.0.14441.5.5.0.0.0.0.274.982.1j0j4.5.0....0...1c.1j4.34.mobile-heirloom-serp..3.2.308.Tv3Kvdbyy48

первая страница

Тут сложный момент. Если делать это не библиотекчным решением, то это должно быть что-то, что не пересекается с имеющимися пользовательскими функциями. Тоесть сделать borrow(x) - нельзя, у пользователей может быть функция borrow, а мы её таким образом сломаем. можно сделать auto y = borrow x; но надо продумать граничные случаи. Так например, хотим ли мы позволять делать borrow x; без захвата возращённого значения? Если да - то будут проблемы с тем, что у пользователя может быть класс borrow

если была borrow(Some &&x) и мы введем template<T> std::borrow(T &&x) то ничего не сломается, ибо пользовательская перегрузка будет приоритетнее шаблонной если была template<T>(T &&x), то компилятор грязно выругается "ambiguous function call/declaration" если был class borrow{}; borrow x; и мы введём keyword borrow, то компилятор грязно выругается "нельзя использовать ключевое слово в качестве идентификатора" что я упускаю, помимо фобии комитета "нельзя чтобы -std=c++43 вместо -std=c++40 приводил к ошибкам компиляции"?

//ну или я неправильно понял озвученные проблемы

https://www.google.com/search?q=auto+square+brackets+assignment+c%2B%2B&newwindow=1&client=firefox-b&oq=auto+square+brackets+assignment+c%2B%2B&gs_l=mobile-heirloom-serp.3...12662.14067.0.14441.5.5.0.0.0.0.274.982.1j0j4.5.0....0...1c.1j4.34.mobile-heirloom-serp..3.2.308.Tv3Kvdbyy48

Без гугл аккаунта structured binding далеко не первая выдача поиска

Без гугл аккаунта structured binding далеко не первая выдача поиска

но первая страница

если была borrow(Some &&x) и мы введем template<T> std::borrow(T &&x) то ничего не сломается, ибо пользовательская перегрузка будет приоритетнее шаблонной если была template<T>(T &&x), то компилятор грязно выругается "ambiguous function call/declaration" если был class borrow{}; borrow x; и мы введём keyword borrow, то компилятор грязно выругается "нельзя использовать ключевое слово в качестве идентификатора" что я упускаю, помимо фобии комитета "нельзя чтобы -std=c++43 вместо -std=c++40 приводил к ошибкам компиляции"?

Если в namespace std:: то всё хорошо Если ключевое слово - то оно не должно ломать старый код (да, это "нельзя чтобы -std=c++43 вместо -std=c++40 приводил к ошибкам компиляции")

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

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

эммм, потому что это по вине компилятора, а не Стандарта

Стандарт не виноват, что ваш код ломается при смене компилятора

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

А ведь это с поппыткой сохранения совместимости... Представляете какой трешак начинётся, если даже не пытаться

(но всё же даже Стандарт иногда ломает обратную совместимость)

мне кажется, это довольно фундаментальная фича, как rvalue references, которую просто нельзя пихать в стандартную библиотеку, ибо это относится полностью только к этапу компиляции.

просто для меня ситуация "обновили/поменяли компилятор/либу -> чиним ошибки компиляции" не то что не является не ожиданной, её наоборот, всецело ожидаешь ибо "новые цацки завезли, старый хлам вывезли, а у нас наверняка где-то этот хлам был нужен в давнокоде" переезд без ремонта - это безусловно было бы здорово, но это скорее приятный бонус нежели цель

а где-то там комитет трясётся "не, нельзя auto_ptr удалить, про него даже в книжках успели написать, и кейворд abstract нельзя вводить, вдруг у кого-то есть bool abstarct;", и это делает меня грустить, хоть я и понимаю их аргументировку

а для чего abstract?

да от балды, первый кейворд из C# который вспомнился)

да от балды, первый кейворд из C# который вспомнился)

await

Optimizing is-multiple checks with modular arithmetic http://duriansoftware.com/joe/Optimizing-is-multiple-checks-with-modular-arithmetic.html?

Завёл для GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87232 Автор в статье говорит что завёл сам для clang ( но я тикет не нашёл)

enum {yellow, black} kek; const char* str = typeid(-+-+-+kek).name(); 2 вопроса: 1) Почему это работает? 2) Почему тип такого выражения - int? Что интересно, с enum class так сделать не получится

Хм после введения вашей штуки с мувом будет можно писать последовательностьвызововбейздапи типобезопасно

Foo obj; auto obj = do1(transfer(obj)); auto obj = do2(transfer(obj)); auto obj = do3(transfer(obj));

Хм

enum {yellow, black} kek; const char* str = typeid(-+-+-+kek).name(); 2 вопроса: 1) Почему это работает? 2) Почему тип такого выражения - int? Что интересно, с enum class так сделать не получится

А что тебя смущает то? Какое выражение int?

А что тебя смущает то? Какое выражение int?

Внутри typeid

enum не создает новый тип

Можешь считать псевдонимом