OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 22:14

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




Начать новую тему Ответить на тему  [ Сообщений: 69 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
СообщениеДобавлено: Пятница, 04 Декабрь, 2020 18:51 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Александр К писал(а):
Если движок форума позволяет, давайте проведём опрос: каким методом будем решать проблему. Лично я за введение LONGCHAR с UTF32. Тот, кто хочет сэкономить память, пусть пользуется существующим CHAR.


Выношу ещё раз вниз решение, которое лично мне кажется оптимальным:
viewtopic.php?p=112613#p112613

Только тогда нужно вводить тип, который гарантированного размера 16бит. Как сейчас фиксирован CHAR. Для тех, кто хочет точного указания. CHAR16, например. А CHAR сделать 32 бит/16 бит от режима компилятора.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Декабрь, 2020 22:58 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Илья Ермаков писал(а):
Но можно принять размерность CHAR решением этапа компиляции.


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

Предлагаю провести анализ ситуаций.

Я полагаю, условно можно разделить программы на А) прикладные и Б) системные.

А) Прикладным программам дела нет до того, какой размерности CHAR. Главное - это (абстрактное) множество всех доступных литер. Значение переменной типа CHAR всегда принадлежит этому множеству. В идеале, если прикладная программа написана грамотно, от изменения представления CHAR вообще не должна зависеть ее работа. Это, кмк, и было надеждой ЯВУ.

Б) Для некоторых системных программ может иметь значение размерность типа CHAR. Причем в двух случаях.
Б1) когда нужно взаимодействовать с внешним беспорядочным миром, который оперирует адресами и буферами вместо литер и строк. (См. LinLibc.printf, например)
Код:
   TYPE LinLibc.PtrSTR* = POINTER TO ARRAY [untagged] OF SHORTCHAR;
   PROCEDURE [ccall] LinLibc.printf* (s: PtrSTR): int;

Б2) когда нужны какие-нибудь фокусы с упаковкой. Например, компилятор, генерируя код, вставляет этот код в ARRAY OF SHORTCHAR; ядро кое-где предоставляет метасведения в виде SHORTCHAR.
Код:
   TYPE DevCPE.CodeBlock = POINTER TO ARRAY CodeLength OF SHORTCHAR;
   PROCEDURE Kernel.GetRefVar (VAR ref: INTEGER; OUT mode, form: SHORTCHAR; OUT desc: Type; OUT adr: INTEGER; OUT name: Utf8Name


Б1, кмк, адекватно можно закрыть с помощью имеющегося SHORTCHAR. Но, будь моя воля, я бы упихал его в SYSTEM - раз уж он нужен для системных программ. Могу тут сослаться в свою поддержку на документ
Programming conventions писал(а):
3 Basic types

Use the types INTEGER, REAL and CHAR as defaults. BYTE, SHORTINT, LONGINT, SHORTREAL and SHORTCHAR should only be used if there is a strong particular reason to justify this choice. The auxiliary types are there mainly for interfacing purposes, for packing of very large structures, or for computation of extremely large integers. This rule is more important for exported interfaces than for hidden implementations, of course.

Эти типы могут создавать иллюзию экономии памяти, однако там, в памяти, все настолько безжалостно выравнивается, что в амд64 при передаче в стек булевых значений КПД составляет 1/64.
Эти типы в прикладных программах заставляют морочить голову с приведением типов. А так, были бы они в SYSTEM - еще трижды подумаешь, прежде чем ими пользоваться.

Б2) Кмк, этот фокус - использование SHORTCHAR Там, где на самом деле нужно беззнаковое целое, а вовсе не литера. Всамделе, и генератор кода ведь генерирует байты, и ядро в метасведениях передает какие-то байты. Как раз байты, в отличие от литер - понятие системного уровня, а не прикладного. И я полагаю, что использование SHORTCHAR здесь - вынужденная мера ввиду отсутствия понятия байтов в языке. Собственно тип BYTE - это не байт, это знаковое целое, которое влезает в 8 бит. В Обероне, емнип, был тип SYSTEM.BYTE - это как раз был беззнаковый байт, просто 8 бит. Его из КП исключили. Но в недрах компилятора он остался: там есть Byte, который соответствует SYSTEM.BYTE, и есть Int8, который соответствует просто BYTE. И правила обращения с ними соответственно беззнаковые и знаковые. Как я понимаю, СР2 компилировал и Оберон-программы (может, и сейчас умеет, если опцию включить).
Поэтому есть и такой вариант:
Language report писал(а):
CHAR the characters of the Unicode character set (MIN(CHAR) .. MAX(CHAR))

Platform-specific issues писал(а):
SYSTEM.BYTE the integers between 0 and 255


а SHORTCHAR... может, в топку его?


Коллеги, какие ситуации следует еще добавить к предложенному анализу?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Декабрь, 2020 23:15 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Я внимательно сейчас перечитал интерфейс (Lin)Kernel, и вот все случаи SHORTCHAR:
Код:
   TYPE
      ItemExt = POINTER TO ABSTRACT RECORD
         (e: ItemExt) GetSStringVal (OUT x: ARRAY OF SHORTCHAR; OUT ok: BOOLEAN), NEW, ABSTRACT;
         (e: ItemExt) PutSStringVal (IN x: ARRAY OF SHORTCHAR; OUT ok: BOOLEAN), NEW, ABSTRACT;
      END;
      Module = POINTER TO RECORD [untagged]
         names-: POINTER TO ARRAY [untagged] OF SHORTCHAR;
      END;

      Utf8Name = ARRAY 256 OF SHORTCHAR;

   PROCEDURE GetRefVar (VAR ref: INTEGER; OUT mode, form: SHORTCHAR; OUT desc: Type; OUT adr: INTEGER; OUT name: Utf8Name);

   PROCEDURE StringToUtf8 (IN in: ARRAY OF CHAR; OUT out: ARRAY OF SHORTCHAR; OUT res: INTEGER);

   PROCEDURE Utf8ToString (IN in: ARRAY OF SHORTCHAR; OUT out: ARRAY OF CHAR; OUT res: INTEGER);


Получается три случая использования SHORTCHAR:
1) в связи со строками в кодировке Utf8
2) в связи со строками в кодировке Latin-1 (то, что в ItemExt)
3) в связи с непойму чем - в процедуре GetRefVar, вполне можно было обойтись без SHORTCHAR

Случай 1) прекрасно поддается изоляции в библиотеку: если откуда-то прилетают или куда-то нужно отослать Утф8 - воспользоваться модулем Utf, а внутри ББ пользоваться CHAR
Случай 2) - ну, вероятно, можно признать его obsolete или outdated. Как я понимаю, в интерфейсах появилось WriteString и WriteSString как переходная мера; кмк, уже можно признать переход завершившимся, не?
Случай 3) мне непонятен; предлагаю его признать огрехом и в амд64 не тащить.

Выходит, даже анализ интерфейса ядра - уж куда системней! - не дает существенных оснований для SHORTCHAR.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Февраль, 2021 15:12 

Зарегистрирован: Воскресенье, 06 Август, 2017 19:33
Сообщения: 79
Цитата:
Получается, чтобы истолковать программу, недостаточно держать в руках программу и определение языка. Необходимо еще знать, с какими опциями предполагается компилировать эту программу. Или с какими она была скомпилирована. Т.е. фактически это две разных программы. Или три? тридцать три? ведь у компилятора может много быть опций.


А что, если сделать какой-нибудь модуль Char, и входе выполнения программы менять разрядность, например так: Char.SetSize (16) или Char.SetSize (32). Это реализовать конечно сложнее, чем статическое указание при компиляции, зато какая свобода появляется.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 24 Март, 2021 05:12 
Аватара пользователя

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 248
Откуда: г. Рига, Латвийская ССР
Александр Ильин писал(а):
Думается мне, что эта разница между Del и Backspace на самом деле происходит от того, что детали реализации композитных символов протекают на верхний уровень, и никто просто об этом не подумал.


Когда пишешь букву Ё, то при нажатии забоя (backspace) удаляться она должна сразу целиком.
Но когда пишешь слово "ударе́ние", в котором после буквы Е набрана литера с кодом 301H, то если поставить курсор после "е́" и нажать забой, удалиться должно ударение. Это очень удобно.

Ещё раз повторю, что с буквами Ё, Й и многими-многими другими всё должно быть по-простому - удаляться они должны сразу.

Александр Ильин писал(а):
Что мешает удалить "е" из-под точечек с помощью Del и подставить "o", чтобы получить "ö"?


То, что точки оказались бы натянуты на какую-то другую литеру (на пробел, на кавычку, на что-то другое).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 24 Март, 2021 09:54 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Александр К писал(а):
и входе выполнения программы менять разрядность
чур меня


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Ноябрь, 2021 21:59 
Аватара пользователя

Зарегистрирован: Пятница, 20 Январь, 2006 13:18
Сообщения: 37
После десяти лет отсутствия зашел поностальгировать и не прогадал. Поддержка юникода как была на уровне двухбайтных символов так и осталась.

Сделайте уже наконец биндинги к ICU и не мучайтесь больше. Там не так много работы. Для всех операций сложнее склейки двух строк используйте функции из ICU (даже для вычисления длины строки как строки, а не как массива двухбайтных чисел) и выберите какую-нибудь одну нормализацию, через которую должны проганяться все входные текстовые данные.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Ноябрь, 2021 00:06 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
alek111 писал(а):
...Сделайте уже наконец биндинги к ICU и не мучайтесь больше...
У вас нет ни совести, ни сострадания, ни понимания существа и соли момента!!!
"А - поговорить?!"(тм)
А - почесать ЧСВ?!
Вы - что? "Сделайте уже наконец"! Вы - что себе позволяете?! А - творчество? Так, чтобы - аж - до пердячьего пара?!
Цель и результат - ничто! Процесс - всё! Зарубите это себе на носу и не путайтесь под ногами у аксакалов, акынов и ковбоев!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 06:23 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
alek111 писал(а):
Сделайте уже наконец биндинги к ICU и не мучайтесь больше. Там не так много работы.
там много работы, потому что TextModels не в курсе идиотии с композитингом. и многие другие места тоже. намного проще просто выкинуть композитинг и прибить гвоздями UCS-2. кто в это не вписался — пусть идёт мимо. вот когда юникод заменят на что-то косистентное — тогда и можно заморачиваться правильной реализацией.


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

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


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

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


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

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