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

W>>>Понадобилось? Зачем? Почему не подошло готовое?
M>>Искать дольше
W>То есть вопрос правильности не стоит?

Стоит, конечно.

W>>>Ну, видимо невнимательно прочитал ту тему. Вот например:
M>>Внимательно. Те компиляторы, которые я использую, все делают как нужно. Пока это устраивает.
W>Ясно. Хотя всё равно непонятно зачем оставлять явные ошибки, если можно сразу написать правильно.

Тут даже не так. signed версии я добавил для ассортимента, копипастой с unsigned, и просто не подумал По идее, переполнения при сложении signed не может быть от слова никогда, а если оно вдруг как-то случилось, то это да, UB Со знаковыми может быть только займ при вычитании, надо будет подумать на эту тему.

M>>Хотя эта копипаста самому не очень нравится,
W>В этом коде, кстати говоря, ещё один довольно сомнительный подход используется. Зачем нужно проводить вычисления над 8-,16-,32-х битными числами если длина машинного слова 64 бита (судя по наличию UINT64). Вместо этого просто сразу расширяешь все короткие числа до машинного слова, обрабатывать их как обычно, а потом, если нужно, при упаковке обратно проверять все переполнения.

Для ассортимента
Иногда пишу на TurboC 1.0 для 186 При нужде переделать под C можно без проблем, если все уже работает.
И на x86 маш. слово все-таки 32 разряда, возможно есть mul32, который дает 64х-битный результат, но не уверен, пусть с этим компилятор разбирается
Вопрос в том, как умножать числа, которые дают результат шире маш. слова. И для которых нет (или есть, но сильно нестандартные) интегральные типы с большей разрядностью.

W>Это же дико (и медленно) умножать два числа через полубайты, если у тебя регистр 64 или 32 бита. Ещё более дико становится если вспомнить, что много где есть возможность умножить пару машинных слов и получить результат двойной длины.

Полубайты?
Ты это уже к алгоритму умножения чисел произвольной длины ?
Где есть возможность умножения с расширением результата? На x86 вроде нет даже сейчас (64-128). Не знаю, есть ли на x64 умножение mul64 со 128-битным результатом. Вроде тоже нет.
Алгоритм умножения, который я стырил у Уоррена, как раз на это и расчитан.

W>В общем, поэтому и спрашивал, зачем это нужно. Ибо сейчас код неправильный, небыстрый и некрасивый (сам просил попинать).
За критику спасибо

W>>>Эта функция у тебя иногда возвращает отрицательный результат вследствие переполнения на минимальном целом.
M>>Это как?
W>integer_abs должна возвращать неотрицательный результат, так? А вот integer_abs<int32_t>(-2147483648) возвращает число меньше нуля, хотя аргумент функции в int32_t помещается.
А, понял мысль. Да, есть такая проблема. Когда вопрос встанет ребром, добавлю safe-версию.

W>Уж не знаю что ты с этим будешь делать, но явно тут прослеживается неконсистентность в подходе — одни функции пытаются сообщать об переполнениях, а другие их игнорируют.
Ну, те которые пытаются, они пытаются это явно сделать
Будет нужна safe integer_abs — сделаю отдельно, а в эту добавлю throw
Она вообще для ассортимента за компанию к integer_sign и sign_multiple сделана, даже и не используется пока

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

Еще раз спасибо за критику