Zorko писал(а):
Возможен такой вариант, что наибольший целый тип платформы, допустим, будет 32 бита, а константы всё ещё могут быть 64-битными. При этом если использовать такую константу прямо, то сразу будет переполнение, но не в месте объявления константы, а в месте использования, что логично. Но такой константе можно найти применение для вычислений во время компиляции
...
Здесь мы видим, что если число выходит за пределы типа LONGINT, то генерируется ошибка 203.
Сейчас нельзя использовать 64-битные константы даже во время компиляции, если наибольший тип целевой платформы 32 бита. Сканер сможет прочитать такую константу, но до вычислений во время компиляции парсер должен построить дерево. Засунуть константу в дерево не удастся - сработает SetIntType для узла. А там идет привязка к параметрам OPM.MinLInt/OPM.MaxLInt, а не к типам КП. В результате будет "одна и та же" ошибка 203.
И это логично - если в ЯП нет 64-битного типа, то не может быть таких переменных, операций, или констант (иначе, какого бы типа они были?). Если каким-то образом нужно написать константное выражение из 64-битных чисел, значение которого меньшей разрядности, то речь идет скорее о "представлении", о способе записи 32-разрядных или 16-разрядных констант через 64-битные. Но представлением занимается обычно сканер, поэтому его придется усложнить. А стоит ли, так ли уж часто нужно задавать константы меньшей разрядности через большие? В любом случае, без существенной переделки транслятора это не сделать.
Цитата:
Что касается возможности задания отрицательного 16-ричного без ун. минуса, то не вижу в этом никаких проблем. Hex-числа вообще очень редко пишут в коде с ун. минусом. Практически во всех ЯП, начиная с ТурбоПаскаля, заканчивая Си, Дельфи, можно задавать знак числа именно так, неявно и без унарного минуса. И Оберон тоже поддерживает эту традицию. Сам смысл 16-ричных чисел в программировании — более компактное представление двоичных разрядов, то есть, как ни крути, это уже шаг к низкому уровню.
Но Офронт, где MaxHDig всегда равно 16, не поддерживает эту традицию для 32-разрядной платформы. Ведь 64-битную константу невозможно задать - она не поместится в узел дерева из-за SetIntType. А все константы меньшей разрядности не будут рассматриваться как заданные в дополнительном коде, потому что у них старшая (шестнадцатая) цифра равна нулю. Получается, что для 32-битной платформы этот способ вообще пропадает: 64-битные константы задать нельзя, а все прочие имеют меньше 16 цифр.
Поэтому считаю, что будет полезно ориентироваться на разрядность целевой платформы - максимальное число цифр должно определяться по максимальному целому типу транслируемого ЯП. Тогда и способ задавать hex-константу будет работать на всех платформах. И достичь этого очень просто, нужно сделать OPM.MaxHDig не константой, а таким же экспортируемым readonly параметром, как MaxLInt. И вычислять OPM.MaxHDig := 2*LIntSize;