OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 06 Август, 2020 04:27

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 78 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 11:31 

Зарегистрирован: Среда, 04 Август, 2010 04:01
Сообщения: 37
Откуда: Сан Хосе, Калифорния, США
Alexey Veselovsky писал(а):
nail_kh писал(а):
Ну так давайте оставим универсальные типы INTEGER и REAL для расчетов, а для работы с битами, масками, сдвигами и т.д. - будем использовать типы с названиями, явно отражающими их разрядность. Если более высокоразрядная платформа поддерживает эти явные типы (а это почти всегда так), то никаких проблем с компиляцией быть не должно. Разумеется, это не относится к случаю, когда программист использует INTEGER (или что вообще немыслимо - REAL) для битовых операций, а BYTE и CHAR - для расчетов. Тут, как говорится, против лома нет приема.

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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 11:49 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
nail_kh писал(а):
Alexey Veselovsky писал(а):
nail_kh писал(а):
Ну так давайте оставим универсальные типы INTEGER и REAL для расчетов, а для работы с битами, масками, сдвигами и т.д. - будем использовать типы с названиями, явно отражающими их разрядность. Если более высокоразрядная платформа поддерживает эти явные типы (а это почти всегда так), то никаких проблем с компиляцией быть не должно. Разумеется, это не относится к случаю, когда программист использует INTEGER (или что вообще немыслимо - REAL) для битовых операций, а BYTE и CHAR - для расчетов. Тут, как говорится, против лома нет приема.

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

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


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


Приложение (и тем более алгоритм) обычно должно работать на нескольких платформах с разной разрядностью. Поэтому очень неплохо бы именно в реализации алгоритма указать какая же ёмкость (минимальная разрядность) целого ему нужна для корректной работы. Это позволит во-первых проще сопровождать код (код самодокументирован будет), во-вторых в случае чего (нет такого типа для данной платформы) получить ошибку компиляции, а не ошибку исполнения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 13:24 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Alexey Veselovsky писал(а):
Приложение (и тем более алгоритм) обычно должно работать на нескольких платформах с разной разрядностью. Поэтому очень неплохо бы именно в реализации алгоритма указать какая же ёмкость (минимальная разрядность) целого ему нужна для корректной работы. Это позволит во-первых проще сопровождать код (код самодокументирован будет), во-вторых в случае чего (нет такого типа для данной платформы) получить ошибку компиляции, а не ошибку исполнения.
На самом деле для одних целочисленных данных крайне желательно указать разрядность, а для других лучше использовать универсальный тип INTEGER (как предлагает nail_kh). ИМХО.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 13:51 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
igor писал(а):
Alexey Veselovsky писал(а):
Приложение (и тем более алгоритм) обычно должно работать на нескольких платформах с разной разрядностью. Поэтому очень неплохо бы именно в реализации алгоритма указать какая же ёмкость (минимальная разрядность) целого ему нужна для корректной работы. Это позволит во-первых проще сопровождать код (код самодокументирован будет), во-вторых в случае чего (нет такого типа для данной платформы) получить ошибку компиляции, а не ошибку исполнения.
На самом деле для одних целочисленных данных крайне желательно указать разрядность, а для других лучше использовать универсальный тип INTEGER (как предлагает nail_kh). ИМХО.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 17:11 

Зарегистрирован: Среда, 04 Август, 2010 04:01
Сообщения: 37
Откуда: Сан Хосе, Калифорния, США
Alexey Veselovsky писал(а):
Какие-то минимальные гарантии даже для универсального типа нужны. А ну как он окажется двубитным?

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 17:29 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Alexey Veselovsky писал(а):
Какие-то минимальные гарантии даже для универсального типа нужны.
Согласен.
Alexey Veselovsky писал(а):
А ну как он окажется двубитным?
Да ладно :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 19:08 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
nail_kh писал(а):
Alexey Veselovsky писал(а):
Какие-то минимальные гарантии даже для универсального типа нужны. А ну как он окажется двубитным?

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


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


Я предпочитаю, по возможности, обходиться без авостов. Потому что авост может привести к реальной аварии.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 19:32 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1093
Откуда: Киев
Alexey Veselovsky писал(а):
А вообще, проблема в том, что ни INTEGER в Обероне (не путать с КП!) ни int в с++ не дает каких-либо гарантий по минимальной разрядности. Полагаю их алгоритм не стал бы работать если б int/INTEGER внезапно оказался бы 8ми битным. Поэтому, если мы говорим о Обероне, то в стандартной (то есть за которую отвечает создатель конкретного компилятора) библиотеке должен быть модуль аналогичный сишному stdint.h.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 20:02 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
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'ом можно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 07:16 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1294
Comdiv писал(а):
Получается почти как в Аде, когда компилятор честно сообщает, что собрать корректную версию для этой платформы не может.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 07:25 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
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.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 08:13 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Alexey Veselovsky писал(а):
Trurl писал(а):
В Обероне можно сделать так же.
Код:
ASSERT(MAX(INTEGER) >= 1000000)

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 08:20 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Kemet писал(а):
Alexey Veselovsky писал(а):
Trurl писал(а):
В Обероне можно сделать так же.
Код:
ASSERT(MAX(INTEGER) >= 1000000)

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

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

ББ, кстати, тоже. Очень жаль, что этого в описании языка нет. То есть что там не уточнен этот момент.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 11:29 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1093
Откуда: Киев
Alexey Veselovsky писал(а):
ББ, кстати, тоже. Очень жаль, что этого в описании языка нет. То есть что там не уточнен этот момент.

Этому способствует встроенность всех частей оператора в язык и возможность вычисления на этапе компиляции, но, пожалуй, явное указание не помешало бы.
Но даже если бы он выдавал ошибку исключительно во время исполнения, компиляцию модуля и вызов процедуры с проверкой можно было бы просто включить как этап сборки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 11:59 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9271
Откуда: Россия, Орёл
Банально в секцию инициализации модуля воткнуть...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 12:47 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1294
Alexey Veselovsky писал(а):
ББ, кстати, тоже. Очень жаль, что этого в описании языка нет. То есть что там не уточнен этот момент.

Да, я случайно наткнулся. Проверял, что размер записи совпадает с заданным, а он не совпал и компилятор ругнулсяю


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 13:55 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Банально в секцию инициализации модуля воткнуть...

Загрузка модуля может быть динамической.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 02 Июль, 2013 19:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9271
Откуда: Россия, Орёл
Ну да, но тем не менее это произойдёт до реального выполнения прикладного кода. А в момент запуска или последующего подключения компонента.

Ну, это не говоря про то, что мы всё-таки имеем статический контроль...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 78 ]  На страницу Пред.  1, 2, 3, 4

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB