freepascal.ru

debi12345 писал(а): Все-таки почему Мартин упирается против наличия универсального базового типа как основы, от которой плясать и создавать производные типы

Правильно он делает, что упирается. Лишние сущности не нужны.

Лишние сущности не нужны

Наоборот ! Вместо множества целых разной длинны, всего один (!) INTEGER-тип (сущность?) - базовый. С опциональной детализацией по диапазону (компилятор внутри переведет в нужный размер под архитектуру).

debi12345 писал(а):Наоборот ! Вместо множества целых разной длинны, всего один (!) INTEGER-тип (сущность?) - базовый. С опциональной детализацией по диапазону (компилятор внутри переведет в нужный размер под архитектуру).

Зачем??? Как Вы будете отражать эту сущность на реальное железо?

Как Вы будете отражать эту сущность на реальное железо

Компилятор имеет всю инфу для такого отображения :

Код: Выделить всё

integer -10..10; // sint8
integer 0..127; // uint8
integer 0..255; // uint8
integer from 0; // uint(MAX_HW_REG_LEN)
integer; // sint(MAX_HW_REG_LEN/2)


debi12345 писал(а):Компилятор имеет всю инфу для такого отображения :

Т.е. сначала надо замапить диапазон на один из "железных типов", а затем замапить этот тип на объявленный тип. Зачем так сложно, тем более что компилятор все равно должен будет уметь обрабатывать все поддерживаемые аппаратные типы?

Опять же, не логично. Объявляем [-10..10] а меняться будет от -127..128, что, кстати, не факт ведь этот диапазон можно замапить и на int32.

Что касается типов-диапазонов из Паскаля, то считаю что их можно выбросить. Используются редко, если начинать массивы с нуля, то будут использоваться еще реже. Их функционал можно заменить Assert, там где нужно.

Объявляем [-10..10] а меняться будет от -127..128, -

На этапе компиляции нарушение диапазона можно выловить сразу. В рантайме - проверять софтварно (специальным кодом с генерацией исключений) перед присвоениями там, где задан диапазоны отличные от 2pwrN (неотлавливаемые аппаратными исключениями-прерываниями - работающими АФАЙК только для MAX_HW_REG_LEN, то есть выход за байт на совремнных процах аппаратно не выловишь). Ран-тайм проверку можно отключить - например в том же GCC есть для этого опция компилятора.

debi12345 писал(а):На этапе компиляции нарушение диапазона можно выловить сразу. В рантайме - проверять софтварно (специальным кодом с генерацией исключений) перед присвоениями там, где задан диапазоны отличные от 2pwrN (неотлавливаемые аппаратными исключениями-прерываниями - работающими АФАЙК только для MAX_HW_REG_LEN, то есть выход за байт на совремнных процах аппаратно не выловишь). Ран-тайм проверку можно отключить - например в том же GCC есть для этого опция компилятора.

Для этого достаточно Assert, зачем усложнять?
А если мне нужно проверить чтобы число было от -10 до 10, но хранилось в int32?

все-таки широкий тип и диапазоны выглядят интереснее. А уже дело компилятора выбрать базовый аппаратный тип.

Лекс Айрин писал(а):все-таки широкий тип и диапазоны выглядят интереснее. А уже дело компилятора выбрать базовый аппаратный тип.

Не все то золото что блестит.

Теряется управляемость.

число было от -10 до 10, но хранилось в int32?

А вот это реально излишнее усложнение
Ясен перец что как обычно :

Код: Выделить всё

var
  i1: integer; // неявный диапазон -MAX_HW_REG_SZ/2 .. +MAX_HW_REG_SZ/2
begin
if ((i < -10) and (i >10)) then ..


debi12345 писал(а):А вот это реально излишнее усложнение

Обычная история если нужно работать с оборудованием.

А если я ошибусь при задании диапазона, например так

Код: Выделить всё

-128 .. +128


как долго я буду искать ошибку?

как долго я буду искать ошибку?

Сразу идти смотреть определение типа - секции TYPE и VAR. Pascal не позволит раскидать эти определения где попало.
Вообще задание разрядности и есть проверка диапазона - только не по реально нужным значениям, а по приближенным к ним 2pwrN. В редких случаях отлавливаемая аппаратными исключениями проца. Чем приближенная проверка лучше точной ? И что мешает задать диапазон константами 2pwrN ?

Mikhail писал(а):Теряется управляемость.

А сейчас будто мы сильно чем-то управляем?

debi12345 писал(а):

проблемы.

Навскидку - да.

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

Для диапазонов также возможен битовый синтаксис, типа :

Код: Выделить всё

i1: integer of 8 bits;
i1: integer:8;

i2: integer of MAX bits; // 32 bits
i2: integer:MAX; // 32 bits

i3: integer of HUGE bits; // 64 bits
i3: integer:HUGE; // 64 bits


Минус этого варианта - отдельные названия базовых типов для знакового и беззнакового, или префикс UNSUIGNED.

Добавлено спустя 12 минут 2 секунды:

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

Взято из GCC, кода ядра и его обвязки ? Там это актуально - потому что среда работы - от суперсерверов до гаджетов MAKE определяет архитектуру, скармиливает ее в компилируемые файлы через DEFINE, а мощный С-ый препроцессор все утрясает через синтаксические макросы (которые иногда корректируют исходник до неузнаваемости).
Раз в Паскале, из-за однопроходности компилятора - нет и не будет мощного препоцессора, можно подумать чем этот функционал заменить.