OberonCore
https://forum.oberoncore.ru/

Подходы к переводу типов в интерф. мод-х внешних библ-к
https://forum.oberoncore.ru/viewtopic.php?f=47&t=2934		 Страница 1 из 1
Автор:  Роман М. [ Вторник, 26 Октябрь, 2010 10:39 ]
Заголовок сообщения:  Подходы к переводу типов в интерф. мод-х внешних библ-к
Код:
TYPE
   (* Delphi types *)
   Cardinal = INTEGER;
   PChar* = POINTER [untagged] TO ARRAY [untagged] OF SHORTCHAR;
  Pointer* = INTEGER;
  Integer* = INTEGER;

  (*LongWord = DWORD;
  THandle = Cardinal;*)
  (* SDL_types.h types *)
  (* Basic data types *)

  Bool = Integer; (* SDL_FALSE, SDL_TRUE *)

  PSInt8 = ^SInt8;
  SInt8 = Shortint;



В интерфейсных модулях сторонних библиотек (большей частью, написанных на C) я считаю верных подходом отделять определение базовых типов в специальные модули. Такие модули, как правило, аппаратно- и компиляторо-зависимы.
Вместо такого описания (как в примере кода) я бы создал отдельный модуль, в котором определил такие типы, как UInt8, Pointer, Integer, Cardinal, PChar и прочие. Затем импортировал бы их в интерфейсном модуле. Так мы добиваемся универсальности при переносе на другие платформы и компиляторы, даже в пределах совместимости между различными компиляторами Оберонов.
Автор:  Илья Ермаков [ Вторник, 26 Октябрь, 2010 11:17 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Резонно.
Автор:  Info21 [ Вторник, 26 Октябрь, 2010 11:52 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Роман М. писал(а):
Вместо этого ...
Пож., уточните формулировку (чего этого?) или измените.
Автор:  Роман М. [ Вторник, 26 Октябрь, 2010 12:31 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Уточнил.

Ещё добавлю. На мой взгляд, при подготовке интерфейсных модулей очень ощущается нехватка соглашений о том как следует описывать типы из сторонних библиотек. Не помешал бы модуль для описания базовых типов, такой как:

Код:
DEFINITION LibsTypesC   (* nonportable (i386) *);

   TYPE
      String = POINTER TO ARRAY [untagged] OF SHORTCHAR;

      BOOL = INTEGER;

      DWORD = UInt32;

      SInt32 = INTEGER;

      UInt32 = INTEGER;

      UInt8 = BYTE;

END LibsTypesC.


Причём, полезно создать для разных компиляторов. Более того, возможно, даже указывать рядом с каждым базовым типом сколько бит он занимает и ссылку на документ, в котором эти соглашения указаны. А то, в будущем, неизвестно как придётся видоизменять программы, чтобы они соответстовали новым нормам типов.
Автор:  Евгений Темиргалеев [ Вторник, 26 Октябрь, 2010 12:37 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Роман М. писал(а):
В интерфейсных модулях сторонних библиотек (большей частью, написанных на C) я считаю верных подходом отделять определение базовых типов в специальные модули. Такие модули, как правило, аппаратно- и компиляторо-зависимы.
Вместо этого я бы создал отдельный модуль, в котором определил бы такие типы, как UInt8, Pointer, Integer, Cardinal, PChar и прочие. Затем я бы импортировал их в интерфейсном модуле. Так мы добиваемся универсальности при переносе на другие платформы и компиляторы, даже в пределах совместимости между различными компиляторами Оберонов.
1) Для ББ (про прочие компилеры не знаю) введением особого модуля для типов Вы не избавитесь от SYSTEM, т.к. его сразу тянет MODULE Aaa ["os-lib.file"].
2) На базе опыта и ощущений: не стал бы я гоняться за универсальностью реализации в интерфейсных модулях (поминая макросы, воркэраунды и проч.). Основная цель, по-моему, сделать интерфейс как можно ближе к [задокументированному] оригинальному. А из-за разницы в языках (напр. Си-Оберон) это не всегда делается одинаково. Например, unsigned int можно как INTEGER перевести, а можно как SET...
3) я придерживаюсь такой схемы: в документации пишу соответствие типов

Думаю, лучше говорить о единообразности процесса переноса, когда будет использоваться не особый модуль, а общие соглашения (именование, выбор правильного типа) по переводу типов, записанные (и обновляемые) в общедоступном месте.

Особые ситуации, по-моему, бывают довольно часто. Если есть общие соглашения --- в случае исключения им можно не следовать. Если есть набор модулей, претендующий на универсальность, придётся часто и сильно ломать голову над тем, как эту универсальность (отсутсвтвие особых ситуаций) обеспечить.
Автор:  Роман М. [ Вторник, 26 Октябрь, 2010 13:09 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Евгений Темиргалеев писал(а):
Роман М. писал(а):
В интерфейсных модулях сторонних библиотек (большей частью, написанных на C) я считаю верных подходом отделять определение базовых типов в специальные модули. Такие модули, как правило, аппаратно- и компиляторо-зависимы.
Вместо этого я бы создал отдельный модуль, в котором определил бы такие типы, как UInt8, Pointer, Integer, Cardinal, PChar и прочие. Затем я бы импортировал их в интерфейсном модуле. Так мы добиваемся универсальности при переносе на другие платформы и компиляторы, даже в пределах совместимости между различными компиляторами Оберонов.
1) Для ББ (про прочие компилеры не знаю) введением особого модуля для типов Вы не избавитесь от SYSTEM, т.к. его сразу тянет MODULE Aaa ["os-lib.file"].
2) На базе опыта и ощущений: не стал бы я гоняться за универсальностью реализации в интерфейсных модулях (поминая макросы, воркэраунды и проч.). Основная цель, по-моему, сделать интерфейс как можно ближе к [задокументированному] оригинальному. А из-за разницы в языках (напр. Си-Оберон) это не всегда делается одинаково. Например, unsigned int можно как INTEGER перевести, а можно как SET...
3) я придерживаюсь такой схемы: в документации пишу соответствие типов

Думаю, лучше говорить о единообразности процесса переноса, когда будет использоваться не особый модуль, а общие соглашения (именование, выбор правильного типа) по переводу типов, записанные (и обновляемые) в общедоступном месте.

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

1. Желательно минимизировать присутствие модуля SYSTEM где бы то ни было.
2. Никаких отличий я не предлагаю. Лишь alias для базовых типов, определённых в отдельном модуле. Сегодня INTEGER занимает 32 бита, завтра - 128. Именно поэтому нужно иметь независимое от компилятора представление типа. Ведь не спроста во многих библиотеках определяются типы UInt32, gchar и тому подобные. Они позволят избежать перелопачивания кода при изменении среды, в которой будет работать ПО.
Автор:  Евгений Темиргалеев [ Вторник, 26 Октябрь, 2010 13:59 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Роман М. писал(а):
1. Желательно минимизировать присутствие модуля SYSTEM где бы то ни было.
2. Никаких отличий я не предлагаю. Лишь alias для базовых типов, определённых в отдельном модуле.
1. Присутствие в смысле "импорт" или "зависимость"? (для ББ) введение модуля с "alias для базовых типов" зависимость от SYSTEM не убирает. Вообще --- желательно, согласен.
2. Конкретный нюанс, с которым сталкивался на практике. Можете записать, как будет выглядеть решение с использованием модуля алиасов?
OglGLUT docu писал(а):
Соответствие между типами Компонентного Паскаля и типами GLUT
...
- int и unsigned int используется тип INTEGER, если они представляют числа;
- int и unsigned используется SET, если они представляют набор битов (например, см. GetModifiers и InitDisplayMode);
Автор:  Евгений Темиргалеев [ Вторник, 26 Октябрь, 2010 14:00 ]
Заголовок сообщения:  Re: Подходы к переводу типов в интерф. мод-х внешних библ-к
Роман М. писал(а):
Сегодня INTEGER занимает 32 бита, завтра - 128. Именно поэтому нужно иметь независимое от компилятора представление типа...
Моё текущее мнение (навязывать не собираюсь): точный прогноз что и как будет "завтра", чтобы найти 100% решение сегодня --- дать не возможно. А тратить силы на полурешение не охота.

"Утро вечера мудренее": надо --- перепишем (если эта библиотека ещё будет существовать, если в ней ещё будет потребность, если .......)
Автор:  Роман М. [ Вторник, 26 Октябрь, 2010 15:18 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Евгений Темиргалеев писал(а):
Роман М. писал(а):
1. Желательно минимизировать присутствие модуля SYSTEM где бы то ни было.
2. Никаких отличий я не предлагаю. Лишь alias для базовых типов, определённых в отдельном модуле.
1. Присутствие в смысле "импорт" или "зависимость"? (для ББ) введение модуля с "alias для базовых типов" зависимость от SYSTEM не убирает. Вообще --- желательно, согласен.
2. Конкретный нюанс, с которым сталкивался на практике. Можете записать, как будет выглядеть решение с использованием модуля алиасов?
OglGLUT docu писал(а):
Соответствие между типами Компонентного Паскаля и типами GLUT
...
- int и unsigned int используется тип INTEGER, если они представляют числа;
- int и unsigned используется SET, если они представляют набор битов (например, см. GetModifiers и InitDisplayMode);


1. Избегать присутствия при импорте, конечно.
2. Можно так:
Код:
MODULE LibsGLUTTypes;

   IMPORT SYSTEM;
   
   TYPE
      Address = POINTER TO RECORD [untagged] END;
      (*
      Address* = INTEGER;
      *)
      Enum* = INTEGER;
      Boolean* = SHORTCHAR;
      Bitfield* = SET;
      Int* = INTEGER;
      Sizei* = INTEGER;
      Ubyte* = SHORTCHAR;
      Byte* = BYTE;
      Short* = SHORTINT;
      Ushort* = SHORTINT;
      Uint* = INTEGER;
      Float*     = SHORTREAL;
      Clampf* = SHORTREAL;
      Double* = REAL;
      Clampd* = REAL;
      
      PtrSTR* = POINTER TO ARRAY [untagged] OF SHORTCHAR;
      int* = INTEGER;

END LibsGLUTTypes.


Код:
MODULE LibsGLUT ["glut32"];

   IMPORT Types := LibsGLUTTypes;
   
   TYPE
      int* = Types.int;
      PtrSTR* = Types.PtrSTR;

   (* GLUT Initialization sub-API *)
   PROCEDURE Init* ['glutInit'] (VAR argc: int; VAR argv: PtrSTR);

END LibsGLUT.
Автор:  Info21 [ Вторник, 26 Октябрь, 2010 17:30 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Роман М. писал(а):
Сегодня INTEGER занимает 32 бита, завтра - 128.
В КП INTEGER зафиксирован в 32 бита. 128 -- это HUGEINT.
Автор:  Роман М. [ Среда, 27 Октябрь, 2010 10:16 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Info21 писал(а):
Роман М. писал(а):
Сегодня INTEGER занимает 32 бита, завтра - 128.
В КП INTEGER зафиксирован в 32 бита. 128 -- это HUGEINT.

Если завтра выйдет новая версия сообщения об языке КП с указанием размера нового размера INTEGER, то что делать с ПО, написанным под предыдущие версии? Возможен вариант, что ПО придётся адаптировать под новые версии компилятора.
С другой стороны, тип INTEGER имеет различный размер среди разных версий компиляторов Оберонов. Как тогда можно гарантировать компиляцию программы?

Чтобы не перелопачивать весь код, я могу лишь заменить alias базового типа в одном модуле, а затем скомпилировать проект заново. Разве так не выгоднее?
Автор:  Valery Solovey [ Среда, 27 Октябрь, 2010 14:41 ]
Заголовок сообщения:  Re: Подходы к переводу типов в интерф. мод-х внешних библ-к
Смотря для чего. Если ПО уже было написано для 32, то значит, что оно сможет корректно работать и на машине с 128 (правда, возможно, медленнее при прочих равных).

А если делается обновление программы для работы со 128 (допустим, эти 128 открывают новые возможности), то перелопачивание кода будет долгим.
Автор:  Info21 [ Среда, 27 Октябрь, 2010 16:10 ]
Заголовок сообщения:  Re: Давайте адаптируем для ББ/XDS библиотеки SDL, SQLite и Z
Роман М. писал(а):
Если завтра выйдет новая версия сообщения об языке КП с указанием размера нового размера INTEGER, то
А с какого бодуна это может произойти?

Этак от определения любого языка можно ожидать, что оно в любой момент поменяется так, что мама не горюй.
Так и жить нельзя будет :)
Автор:  id_ler [ Четверг, 28 Октябрь, 2010 16:11 ]
Заголовок сообщения:  Re: Подходы к переводу типов в интерф. мод-х внешних библ-к
Евгений Темиргалеев писал(а):
Думаю, лучше говорить о единообразности процесса переноса, когда будет использоваться не особый модуль, а общие соглашения (именование, выбор правильного типа) по переводу типов, записанные (и обновляемые) в общедоступном месте.
Соответствие между типами данных удобно собрать в одной таблице, как сделано, например, на http://www.zel.org/oberon/osci.htm
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/