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

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

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



Если на платформе нет int32 — придется обходится без него ;( Но потребность в арифметике, которая превышает разрядность аппаратуры, никуда не исчезает.

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

Ну, sizeof + CHAR_BITS помогают

M>> Во всех железных архитектурах так или иначе какие-то флаги выставляются, а из C++, да и из C, до них не добраться. Большой недостаток для языка, который декларирует поддержку самых низкоуровневых деталей.Имхо, конечно. "C", вон, вообще как "переносимый асм" декларируется, а таких нужных фич нет.
W>«Переносимый асм» не означает, что ты скопировал программу на другую архитектуру и она заработала.

Кто же спорит

W>Но он никак не поможет изменить взаимодействие файловой системой, с ОС, права доступа к памяти, особенности ввода-вывода — тут всё настолько разнообразно, что просто нельзя это никак уровнять.
Ну, к аппаратной платформе это мало отношения имеет.

W>Часто стараются засунуть это в какие-то библиотеки с глаз долой. Но хотя библиотека, реализующая putchar('a'), и написана на переносимом С, но вот именно печать символа для каждой платформы написана по своему непереносимо.
Ну и хотелось бы подобных стандартных функций, которые реализованы максимально эффективно для конкретной платформы, и поддерживаются производителем, а не группой опен-сорц энтузиастов или вообще своими силами.

W>Аналогично и с сигнализацией переполнения — везде всё настолько по-разному реализовано, что какого-то единого интерфейса предложить нельзя.
Есть процессоры без флаговых регистров? А язык C для них есть?
Intel, ARM, MIPS — есть флаги; контроллеры всякие — все, что видел, тоже с флаговым регистром в том или ином виде. Поведение несколько отличается, но это как раз повод просто упрятать конкретную реализацию в стд библиотеку. Просто стандарт обязывал бы производителя платформы поддерживать еще пару-тройку функций, вот и все.


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

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

Ну, это да. Но как там с переполнениями?

Ладно, мы тут уже далеко отошли от изначальной темы, надо завязывать треп