OberonCore
https://forum.oberoncore.ru/

BlackBox 64
https://forum.oberoncore.ru/viewtopic.php?f=2&t=2439		 Страница 4 из 4
Автор:  nail_kh [ Понедельник, 01 Июль, 2013 11:31 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
nail_kh писал(а):
Ну так давайте оставим универсальные типы INTEGER и REAL для расчетов, а для работы с битами, масками, сдвигами и т.д. - будем использовать типы с названиями, явно отражающими их разрядность. Если более высокоразрядная платформа поддерживает эти явные типы (а это почти всегда так), то никаких проблем с компиляцией быть не должно. Разумеется, это не относится к случаю, когда программист использует INTEGER (или что вообще немыслимо - REAL) для битовых операций, а BYTE и CHAR - для расчетов. Тут, как говорится, против лома нет приема.

Как я описал выше, для расчетов "универсальные" (то есть без каких-либо гарантий) типы INTEGER и REAL также не годятся.

В этом плане лучше всего конечно сделано в Аде.


Гарантии отсутствуют только при переходе с более высокоразрядной платформы на более низкоразрядную. Но при таком переходе проблемы как раз ожидаются и программист знает, что надо принять меры. При переходе на более высокоразрядную вообще то говоря было бы логичным ожидать что проблем с переполнением не возникнет. Разумеется, это не относится к ситуации использования INTEGER для битовых операций или в качестве адрес памяти и т.д. Именно это порождает проблемы при переходе.
Автор:  Alexey Veselovsky [ Понедельник, 01 Июль, 2013 11:49 ]
Заголовок сообщения:  Re: BlackBox 64
nail_kh писал(а):
Alexey Veselovsky писал(а):
nail_kh писал(а):
Ну так давайте оставим универсальные типы INTEGER и REAL для расчетов, а для работы с битами, масками, сдвигами и т.д. - будем использовать типы с названиями, явно отражающими их разрядность. Если более высокоразрядная платформа поддерживает эти явные типы (а это почти всегда так), то никаких проблем с компиляцией быть не должно. Разумеется, это не относится к случаю, когда программист использует INTEGER (или что вообще немыслимо - REAL) для битовых операций, а BYTE и CHAR - для расчетов. Тут, как говорится, против лома нет приема.

Как я описал выше, для расчетов "универсальные" (то есть без каких-либо гарантий) типы INTEGER и REAL также не годятся.

В этом плане лучше всего конечно сделано в Аде.


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


Приложение (и тем более алгоритм) обычно должно работать на нескольких платформах с разной разрядностью. Поэтому очень неплохо бы именно в реализации алгоритма указать какая же ёмкость (минимальная разрядность) целого ему нужна для корректной работы. Это позволит во-первых проще сопровождать код (код самодокументирован будет), во-вторых в случае чего (нет такого типа для данной платформы) получить ошибку компиляции, а не ошибку исполнения.
Автор:  igor [ Понедельник, 01 Июль, 2013 13:24 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
Приложение (и тем более алгоритм) обычно должно работать на нескольких платформах с разной разрядностью. Поэтому очень неплохо бы именно в реализации алгоритма указать какая же ёмкость (минимальная разрядность) целого ему нужна для корректной работы. Это позволит во-первых проще сопровождать код (код самодокументирован будет), во-вторых в случае чего (нет такого типа для данной платформы) получить ошибку компиляции, а не ошибку исполнения.
На самом деле для одних целочисленных данных крайне желательно указать разрядность, а для других лучше использовать универсальный тип INTEGER (как предлагает nail_kh). ИМХО.
Автор:  Alexey Veselovsky [ Понедельник, 01 Июль, 2013 13:51 ]
Заголовок сообщения:  Re: BlackBox 64
igor писал(а):
Alexey Veselovsky писал(а):
Приложение (и тем более алгоритм) обычно должно работать на нескольких платформах с разной разрядностью. Поэтому очень неплохо бы именно в реализации алгоритма указать какая же ёмкость (минимальная разрядность) целого ему нужна для корректной работы. Это позволит во-первых проще сопровождать код (код самодокументирован будет), во-вторых в случае чего (нет такого типа для данной платформы) получить ошибку компиляции, а не ошибку исполнения.
На самом деле для одних целочисленных данных крайне желательно указать разрядность, а для других лучше использовать универсальный тип INTEGER (как предлагает nail_kh). ИМХО.

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

То есть что-то вроде int_least32_t (как минимум, 32 бита) из stdint.h.
Автор:  nail_kh [ Понедельник, 01 Июль, 2013 17:11 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
Какие-то минимальные гарантии даже для универсального типа нужны. А ну как он окажется двубитным?

То есть что-то вроде int_least32_t (как минимум, 32 бита) из stdint.h.


В рантайме такая гарантия уже есть. Это авост при переполнении. Что касается этапа компиляции - то не хотелось бы перегружать базовые типы еще какими то новыми типами. Проще это указать в опциях компилятора.
Автор:  igor [ Понедельник, 01 Июль, 2013 17:29 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
Какие-то минимальные гарантии даже для универсального типа нужны.
Согласен.
Alexey Veselovsky писал(а):
А ну как он окажется двубитным?
Да ладно :)
Автор:  Alexey Veselovsky [ Понедельник, 01 Июль, 2013 19:08 ]
Заголовок сообщения:  Re: BlackBox 64
nail_kh писал(а):
Alexey Veselovsky писал(а):
Какие-то минимальные гарантии даже для универсального типа нужны. А ну как он окажется двубитным?

То есть что-то вроде int_least32_t (как минимум, 32 бита) из stdint.h.


В рантайме такая гарантия уже есть. Это авост при переполнении. Что касается этапа компиляции - то не хотелось бы перегружать базовые типы еще какими то новыми типами. Проще это указать в опциях компилятора.


Я предпочитаю, по возможности, обходиться без авостов. Потому что авост может привести к реальной аварии.
Автор:  Comdiv [ Понедельник, 01 Июль, 2013 19:32 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
А вообще, проблема в том, что ни INTEGER в Обероне (не путать с КП!) ни int в с++ не дает каких-либо гарантий по минимальной разрядности. Полагаю их алгоритм не стал бы работать если б int/INTEGER внезапно оказался бы 8ми битным. Поэтому, если мы говорим о Обероне, то в стандартной (то есть за которую отвечает создатель конкретного компилятора) библиотеке должен быть модуль аналогичный сишному stdint.h.

Если в стандарте с++ нет гарантий минимальной разрядности(что сомнительно), то это шаг назад по сравнение даже со стандартом Си 89-года. В ANSI-C во-первых сказано, что INT_MAX>=32767, во-вторых можно написать так
Код:
#if INT_MAX < 1000000
   "мало!!!"
#endif

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

Определение же языка Оберон не является законченным с точки зрения стандарта, но может лишь послужить основой для него.
Автор:  Alexey Veselovsky [ Понедельник, 01 Июль, 2013 20:02 ]
Заголовок сообщения:  Re: BlackBox 64
Comdiv писал(а):
Alexey Veselovsky писал(а):
А вообще, проблема в том, что ни INTEGER в Обероне (не путать с КП!) ни int в с++ не дает каких-либо гарантий по минимальной разрядности. Полагаю их алгоритм не стал бы работать если б int/INTEGER внезапно оказался бы 8ми битным. Поэтому, если мы говорим о Обероне, то в стандартной (то есть за которую отвечает создатель конкретного компилятора) библиотеке должен быть модуль аналогичный сишному stdint.h.

Если в стандарте с++ нет гарантий минимальной разрядности(что сомнительно), то это шаг назад по сравнение даже со стандартом Си 89-года. В ANSI-C во-первых сказано, что INT_MAX>=32767,

Посмотрел внимательней на стандарт. Там забавно. Стандарт С++ определяет INT_MAX в файле climits, который, как далее указывается, имеет то же содержимое что и limits.h, а limits.h берется из Сишного стандарта, на который имеется там ссылка. Следовательно всё что справедливо для C89/90 (касаемо INT_MAX), то справедливо и для С++98. Так что гарантия таки есть. int минимум 16ти битный.

Comdiv писал(а):
во-вторых можно написать так
Код:
#if INT_MAX < 1000000
   "мало!!!"
#endif

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

Идея хороша. Хотя конечно лучше так:
Код:
#if INT_MAX < 1000000
    #error int too small
#endif

Ну, или static assert'ом можно.
Автор:  Trurl [ Вторник, 02 Июль, 2013 07:16 ]
Заголовок сообщения:  Re: BlackBox 64
Comdiv писал(а):
Получается почти как в Аде, когда компилятор честно сообщает, что собрать корректную версию для этой платформы не может.

В Обероне можно сделать так же.
Код:
ASSERT(MAX(INTEGER) >= 1000000)
Автор:  Alexey Veselovsky [ Вторник, 02 Июль, 2013 07:25 ]
Заголовок сообщения:  Re: BlackBox 64
Trurl писал(а):
Comdiv писал(а):
Получается почти как в Аде, когда компилятор честно сообщает, что собрать корректную версию для этой платформы не может.

В Обероне можно сделать так же.
Код:
ASSERT(MAX(INTEGER) >= 1000000)

Это не будет ведь ошибкой компиляции в случае если INTEGER слишком мелок. А проверка в рантайме нас не устраивает.

Зато можно, сделать так (на КП, проверил на ББ - работает):
Код:
MODULE Test;
    TYPE Check = ARRAY SIZE(INTEGER)-3 OF CHAR;
END Test.


Тут если INTEGER будет меньше 4 байт, то будет ошибка компиляции, соответственно можно проверить не только на 4 байта, но и на любое иное число. Аналогично делается с MAX/MIN (только нужно постараться, чтобы слишком больших значений не выходило). Вот такой вот, static assert.
Автор:  Kemet [ Вторник, 02 Июль, 2013 08:13 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
Trurl писал(а):
В Обероне можно сделать так же.
Код:
ASSERT(MAX(INTEGER) >= 1000000)

Это не будет ведь ошибкой компиляции в случае если INTEGER слишком мелок. А проверка в рантайме нас не устраивает.

Компилятор Активного Оберона выдаст ошибку времени компиляции
Автор:  Alexey Veselovsky [ Вторник, 02 Июль, 2013 08:20 ]
Заголовок сообщения:  Re: BlackBox 64
Kemet писал(а):
Alexey Veselovsky писал(а):
Trurl писал(а):
В Обероне можно сделать так же.
Код:
ASSERT(MAX(INTEGER) >= 1000000)

Это не будет ведь ошибкой компиляции в случае если INTEGER слишком мелок. А проверка в рантайме нас не устраивает.

Компилятор Активного Оберона выдаст ошибку времени компиляции

ББ, кстати, тоже. Очень жаль, что этого в описании языка нет. То есть что там не уточнен этот момент.
Автор:  Comdiv [ Вторник, 02 Июль, 2013 11:29 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
ББ, кстати, тоже. Очень жаль, что этого в описании языка нет. То есть что там не уточнен этот момент.

Этому способствует встроенность всех частей оператора в язык и возможность вычисления на этапе компиляции, но, пожалуй, явное указание не помешало бы.
Но даже если бы он выдавал ошибку исключительно во время исполнения, компиляцию модуля и вызов процедуры с проверкой можно было бы просто включить как этап сборки.
Автор:  Илья Ермаков [ Вторник, 02 Июль, 2013 11:59 ]
Заголовок сообщения:  Re: BlackBox 64
Банально в секцию инициализации модуля воткнуть...
Автор:  Trurl [ Вторник, 02 Июль, 2013 12:47 ]
Заголовок сообщения:  Re: BlackBox 64
Alexey Veselovsky писал(а):
ББ, кстати, тоже. Очень жаль, что этого в описании языка нет. То есть что там не уточнен этот момент.

Да, я случайно наткнулся. Проверял, что размер записи совпадает с заданным, а он не совпал и компилятор ругнулсяю
Автор:  Alexey Veselovsky [ Вторник, 02 Июль, 2013 13:55 ]
Заголовок сообщения:  Re: BlackBox 64
Илья Ермаков писал(а):
Банально в секцию инициализации модуля воткнуть...

Загрузка модуля может быть динамической.
Автор:  Илья Ермаков [ Вторник, 02 Июль, 2013 19:24 ]
Заголовок сообщения:  Re: BlackBox 64
Ну да, но тем не менее это произойдёт до реального выполнения прикладного кода. А в момент запуска или последующего подключения компонента.

Ну, это не говоря про то, что мы всё-таки имеем статический контроль...
Страница 4 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/