OberonCore

Такого рода средства рассованы по нескольким модулям.
А системные вызовы, для которых цепочки туда-сюда гонять приходится, нужны не только для модулей реализации ББ. Каждый раз копировать?

В нашей консольной сборке такой модуль был для этих целей выделен. Одна копия кода процедур-преобразователей была только в HostFiles.

Есть какие-то причины, почему так не удобно сделать здесь?

И, второй вопрос, может и HostFiles стоит собирать с опорой на такой модуль, чтобы копий не было вообще?

Да, можно так сделать. И ещё уже наверное можно убрать поддержку всех кодировок, кроме UTF-8.

Да, это было бы хорошо. Сильно прочистит код. Конверсию из UTF8 я бы положил в System, но не в Strings и Kernel, а отдельным модулем.
Или вариант с SHORTCHAR вместо BYTE.

Маленький модуль, только преобразователь UTF8. Его можно линковать в пускач и импортировать в Kernel и HostFiles.

А Strings/Kernel от Utf8 освободятся. Если надо сохранить совместимость, то из Strings сделать трансляцию в Utf8.
Кто что думает на этот счет?

В ветку dev18 добавили модуль System/Mod/Utf8.odc
В нем сейчас реализация скопирована из ядра.
Используем его уже в HostDialog и HostDates версии 1.8-a1.
Планируется везде заменить использование Strings на этот Utf8, где конвертация делается.

В ядро этот модуль не надо импортировать. Ядро должно автономно работать, или вообще откажемся от SHORTCHAR в компиляторе, как Борис предлагает, то и в ядре эти преобразования не понадобятся.

Коллеги, может, пока джин еще в бутылке, стоит переназвать модуль просто Utf? А то потом захочется добавить UTF16, UCS какой-нибудь... Да и читать Utf приятней чем Utf8 )

Согласен. Александр предлагает Unicode тогда назвать. Сможем туда поместить разные кроссплатформенные реализации IsAlpha и т.п.

Unicode? Even better!

А можно назвать Everything и помещать туда, что потребуется.

Что-то я запутался. В kernel же есть преобразования. Или у вас не 1.7?

У меня в bmbb давно есть такой модуль(HostUnicode), что бы не тягать в Kernel, а прикручивать через хук.
(* этот модуль у меня был сгенерирован автоматически утилиткой на сишке, можно ещё оптимизировать выхлоп *)

А что не поместится в Everything, помещать в ОйВсё - даром штоли у нас кириллица поддерживается, и все эти пляски с УТФ8?

Есть одна проблема. Преобразование UTF8 <-> UCS2 это тривиальная задача. А кроссплатформенные реализации IsAlpha -- нет. UCS2 -- это не ASCII. Иван Горячев к этому вопросу подходил серьезно, там целая подсистема.

Я уверен, что подсистему любого размера возможно поместить в один модуль
Правда размер приложение будет увеличиваться. Но зато мы сможем убрать из Strings зависимость от ядра, что важно при разработке динамических библиотек на Блэкбоксе.

В этом подфоруме сейчас больше обсуждаем версию 1.8.
В 1.7.2 кросс-платформенной сборки сейчас статус бета и там никаких нововведений не планируется.

Та все же, вы планируете в 1.8 убрать то, что добавили в 1.7?

Некоторые рациональные изменения будут, которые противоречат решениям, примененным в 1.7
1. которые понизят издержки орловско/воронежской команды по использованию их разработок на новой версии
2. которые упростят поддержку кросс-платформенности

Однако будет больше именений 1.8 от 1.6, чем 1.7 от 1.6 в совокупности.

Возвращаясь к теме utf8, в ядре предлагается убрать экспорт процедур преобразований. А использовать в компиляторе и средствах отладки модуль Unicode, который будет упаковывать/распаковывать идентификаторы в/из ARRAY OF SHORTCHAR.

Снимаем шляпу, вы сделали большое дело! Помещу его сюда, чтобы людям было проще ознакомиться.

Думал думал и придумал, что надо этот код вставлять напрямую в Strings. Раз он кросс-платформенный раз. А также раз Евгений считает, что надо отдельным модулем. А нам модули совершенно не надо плодить в огромном количестве. Есть отличное место для этих процедур - Strings.

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