Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, T4r4sB, Вы писали:

TB>>Здравствуйте, Кодт, Вы писали:

К>А числовые переполнения — это штука очень дискуссионная, и в разных языках к ней разные подходы.
К>Почему компилятор должен догадываться, что вот здесь u8+u8 = u8, а вот здесь уже = u9? А последующий u9-u8 — это u8, u9 или i10?

Ну ок, компилятор не должен догадываться. Пусть будет результат u8. А я возьму инт и не буду про это думать? Можно? Нет, нельзя.

К>Если в русте договорились, что тип результата не продвигается без явных указаний, — ну, делай указания.

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

К>Если есть сущность "смещения только в пределах шахматной доски", то — возможно, автору библиотеки или тебе лично, — придётся завести и сущность "расширенные смещения без гарантии, что они влезли в доску".

Да можно. Только эти хипстеры забыли что не надо плодить сущности без необходимости. А необходимости нет — на простых интах жилось ьы намного проще.

К>Опять же, разрядность этих смещений — "мамой клянусь, i32 мне за глаза и за уши", а вдруг "возьму-ка я float64"?

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

К>А по факту, i128 в большинстве случаев люто избыточно.
К>Если наносекунды с начала эпохи влезают в i64, а ты будешь буферные 64 бита всюду таскать и складывать нули с нулями.

А я не знаю, влезают ли в i64? Там запаса почти нет вродь. Ну если и его хватит то можно и его. Зато голову морочить не надо.

К>Все эти универсальное время, системное, монотонное... это всё разные сущности. Физически разные.
К>std::chrono прямо заставляет тебя сдать экзамен по метрологии, прежде чем ты пойдёшь кодить, — это правда.

Когда я пользовалсяGetTickCount(), time(), rdtsc() и QueryPerformanceCounter() то как то обходился без экзамена. Правда один раз огреб с GetTickCount когда у компа аптайм превысил ограничения типа

К>А какая физическая природа у суммы двух точек?
К>И как к ней, например, аффинные преобразования применять?

Сумма это промежуточный результвт операции "полусумма" у которой есть смысл.
Конечно можно записать это в виде a+(b-a)*0.5, но не всегда. Например тебе надо миллион точек прополусуммировать с данной. Тогда заранее вычислить a*0.5 было бы проще.
А пользы от данной идеи не вижу. Защииа он неверных значений не имеющих физического смысла типа (a+b)*0.6? Ну так если я напишу a+(b-a)*0.6, то мне станет не легче от того что результат сиал гдето примерно посередине a и b