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

W>>Или ты намекаешь, что раз в текущем стандарте языка не упомянут тип uint256_t, то такой подход не масштабируется на гипотетические 128-битные процессоры?
M>А что, в текущем стандарте uint128_t уже есть?
В текущем стандарте даже uint32_t помечен как optional . Это к тому, что с целыми числами в стандарте языка всё совсем не так просто. Тут именно, либо ты используешь что-то вроде int или size_t, имеющие некие гарантии на диапазон, либо вступаешь в область платформо-зависимого поведения. Ну, понятно, что в большинстве случаев int и size_t весьма неплохой выбор и особо можно не переживать. И, отвечая на твой вопрос, uint128_t в текущем стандарте нет. Но, опять же, это довольно мало значит.


M> Во всех железных архитектурах так или иначе какие-то флаги выставляются, а из C++, да и из C, до них не добраться. Большой недостаток для языка, который декларирует поддержку самых низкоуровневых деталей.Имхо, конечно. "C", вон, вообще как "переносимый асм" декларируется, а таких нужных фич нет.
«Переносимый асм» не означает, что ты скопировал программу на другую архитектуру и она заработала. Это означает лишь что после копирования тебе придётся поправить не всю программу (как это было бы с ассемблером), а лишь небольшую её часть. При этом язык сразу предоставляет готовые примитивы вроде sizeof(void*), которые очевидно меняются часто. Но он никак не поможет изменить взаимодействие файловой системой, с ОС, права доступа к памяти, особенности ввода-вывода — тут всё настолько разнообразно, что просто нельзя это никак уровнять.
Часто стараются засунуть это в какие-то библиотеки с глаз долой. Но хотя библиотека, реализующая putchar('a'), и написана на переносимом С, но вот именно печать символа для каждой платформы написана по своему непереносимо.

Аналогично и с сигнализацией переполнения — везде всё настолько по-разному реализовано, что какого-то единого интерфейса предложить нельзя. В лучшем случае что может тут предложить С/C++ — это сноску «implementation defined behaviour» (а часто всё даже заканчивается «undefined behaviour»). Хочешь сигнализации (и прочего детерминизма) — смотри на расширения компилятора — обычно там уже много полезных примитивов есть.

M>А что, в Java такие вещи можно отслеживать? Или там исключениями будут кидаться?
А там виртуальная машина жёстко зафиксирована. Неважно какой у тебя процессор, архитектура, интерпретатор или jit-компилятор, — изволь эмулировать то что написано. Например, тот же long в java с точки зрения программы всегда 64-битный и в two's complement представлении — это гарантируется. Если процессор так не умеет, то реализация обязана, например, программной эмуляцией добиться соответствующего поведения.