0CodErr wrote:А ты про ядро или ЯВУ?

Про ядро.

А если надо UTF-16 передать или UTF-32? Фиксированная кодировка это не гибко

Не надо utf16/32. Должна быть одна кодировка Пусть будет utf8.

За всем этим может следить ядро и конвертировать лишь при необходимости, если не будут совпадать кодировки передающего и принимающего параметры.

Не надо нагружать ядро лишней работой.

0CodErr
То есть в таком случае ты предлагаешь 100500 раз переключать кодировки?
Использовать параметр версии это тоже самое, что и новый заголовок.

Spoiler:

Где у меня написано "кодировка argv[0] всё равно фиксирована"?

Pathoswithin wrote:Где у меня написано "кодировка argv[0] всё равно фиксирована"? :wink

А ты уже отредактировал сообщение, хитрец

Pathoswithin wrote:Использовать параметр версии это тоже самое, что и новый заголовок.

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

В заголовке программы вместо

Code: Select all

version        dd 1

можно сделать

Code: Select all

version        dw 1
encoding       db ?
reserved       db ?

Pathoswithin wrote:То есть в таком случае ты предлагаешь 100500 раз переключать кодировки?

Ты просто посмотри, как работают реальные программы. В основном везде используется одна и та же кодировка за редким исключением. Переключать если придётся, то, всего несколько раз, но не 100500 это точно.

Serge wrote:Не надо нагружать ядро лишней работой.

Ну хорошо, приложения сами будут это делать. Легче от этого? Шило на мыло. В ядре — это значит централизованно только в одном месте, а не в каждом приложении.

Serge wrote:Про ядро.

В основном предлагаемые изменения в первую очередь касаются файловых функций. В которых узкое место — это доступ к диску, а никак не дополнительные проверки, которые, будут практически незаметны. Плюс ещё время на int 64 добавь сюда.

Serge wrote:Не надо utf16/32. Должна быть одна кодировка Пусть будет utf8.

Ну и в итоге тормоза и дополнительные неудобства тебе обеспечены.
UTF32 хороша тем, что можно очень легко обратиться к i-ому символу строки. Это сравнимо по скорости с ASCII. Только здесь 4 байта вместо 1-го. А вот в UTF8 тебе придётся сканировать всю строку до этого символа. Ну и с остальными строковыми функциями та же ситуация. Отказываться от UTF16, думаю, плохая идея. Потому что она в SysFn70 уже используется. Возможно, будет добавлена поддержка в SysFn2, там и 2 байта хватит, так как Basic multilingual plane вполне достаточно для ввода с клавиатуры.
Ну а UTF8 получается, что самая худшая из них. Разве что совместимость с ASCII, но в Колибри, в которой 1,5 более менее серьёзных приложения, эта совместимость просто не нужна. Не с чем совмещаться.

Сейчас драйвера файловых систем работают на UTF-8 и всё в неё перекодируется, так что это "родная" кодировка. И совместимость с ASCII пригодилась.
Всё что в пределах первых 8 байт заголовка принципиально одно и то же. Версия сейчас вообще не используется (кстати, можно использовать под путь для иконки).

Pathoswithin wrote:Версия сейчас вообще не используется (кстати, можно использовать под путь для иконки).

Пока не надо с этим торопиться. Это потенциально целых 32 флага.

Pathoswithin wrote:Сейчас драйвера файловых систем работают на UTF-8 и всё в неё перекодируется, так что это "родная" кодировка. И совместимость с ASCII пригодилась.

Мой вариант позволяет выбрать ту кодировку, которая необходима, тогда, когда это необходимо. То есть, максимально гибко. Зачем искусственно ограничиваться? Мне не понятно.
Если путь будет передаваться в UTF8, то нельзя будет присоединить к нему кириллическое "Папка1" в ASCII. Нужен, значит, конвертер. Только непонятно, зачем не русскоязычному пользователю использовать русифицированный вариант программы. В общем, UTF8 только усложняет всё. Должен быть выбор кодировки. Пусть лучше ядро конвертирует, чем приложению придётся таскать конвертер с собой.

Запустил вот GetPathC.kex в одной из старых сборок #2306

Spoiler:

1.PNG (13.83 KiB)

Viewed 4533 times

Можете сравнить с тем, что выводится сейчас в первом сообщении этой темы viewtopic.php?f=2&t=3429#p67134

0CodErr
Потому, что ср866 базовая кодировка ядра и console.obj. Попробуй напечатать символ, который в cp866 не входит. Если сменить кодировку app_path на utf-8 приложение не сможет его правильно вывести на экран, но сможет распарсить на компоненты.

0CodErr wrote:Мой вариант позволяет выбрать ту кодировку, которая необходима, тогда, когда это необходимо. То есть, максимально гибко. Зачем искусственно ограничиваться? Мне не понятно.

Ты просто предлагаешь раздуть ядро, свалив на него функциональность, которой не хочется заниматься самому. Актуальность UTF32 в прикладных программах 0.(0)% В ядре должна быть одна кодировка. Устанавливать ascii/unicode режим работы ядра в зависимости от флагов в заголовке imho неудачная идея.

Serge wrote:Если сменить кодировку app_path на utf-8 приложение не сможет его правильно вывести на экран, но сможет распарсить на компоненты.

Это сути не меняет:

0CodErr wrote:Если путь будет передаваться в UTF8, то нельзя будет присоединить к нему кириллическое "Папка1" в ASCII. Нужен, значит, конвертер. Только непонятно, зачем не русскоязычному пользователю использовать русифицированный вариант программы. В общем, UTF8 только усложняет всё. Должен быть выбор кодировки. Пусть лучше ядро конвертирует, чем приложению придётся таскать конвертер с собой.

Serge wrote:В ядре должна быть одна кодировка.

Ну дык тогда логичнее сделать её UTF16:

• Она уже используется в SysFn70;
  Её использование легко добавить в SysFn2
  Обработка строк UTF16 происходит быстрее(нужно меньше проверок)

Serge wrote:Ты просто предлагаешь раздуть ядро, свалив на него функциональность, которой не хочется заниматься самому.

Какая по большому счёту разница, где будет этот код? Разница в том, что ядро и так уже работает и с ASCII, и с UTF8, и с UTF16. По-твоему лучше ещё раз продублировать этот код в приложении вместо того, чтобы просто использовать готовый ядерный код? Можно многое вынести из ядра в драйвера и библиотеки. Но раз уж оно сейчас находится в ядре, то и вполне логично, что эту работу будет выполнять ядро.

Serge wrote:Только не APPDATA, а PROC - данные всего процесса.

Лучше APPDATA. Представь, что поток работает с UTF16, и тут БАЦ! и кодировка внезапно сменилась.

Если AppPath будет только в UTF8, то CurrentDirectory и Params вполне могут быть в другой кодировке. Во первых, как приложению узнать, в какой? Во-вторых, снова нужен конвертер.

SysFn70 может возвращать UTF16. Если теперь запустить такое приложение, то нам надо указать и имя файла, которое в UTF16, и параметры, только в какой кодировке не понятно?

Что касается UTF16, то приложение может проверить, не выходит ли строка за рамки UCS2, и тогда можно работать с этой строкой с заметным ускорением.

В общем, если даже делать для unicode одну кодировку, то лучше всего подходит для этого UTF16. переключение ASCII\unicode, разумеется, необходимо.

Лучше APPDATA. Представь, что поток работает с UTF16, и тут БАЦ! и кодировка внезапно сменилась.

1. С чего это она так внезапно изменится ? Её только автор приложения может изменить.
2.Чтобы не было таких внезапных БАЦ, не надо заводить в ядре режимов.

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

Ядро не безразмерно.

Serge wrote:1. С чего это она так внезапно изменится ? Её только автор приложения может изменить.

Ну с таким же успехом и от мьютексов можно отказаться тогда. У нас приложения могут быть многопоточными.

Serge wrote:Ядро не безразмерно.

А никто не спорит же.

0CodErr wrote:Какая по большому счёту разница, где будет этот код? Разница в том, что ядро и так уже работает и с ASCII, и с UTF8, и с UTF16. По-твоему лучше ещё раз продублировать этот код в приложении вместо того, чтобы просто использовать готовый ядерный код? Можно многое вынести из ядра в драйвера и библиотеки. Но раз уж оно сейчас находится в ядре, то и вполне логично, что эту работу будет выполнять ядро.

Ну можно вынести часть ядерного кода в библиотеку. Но всё равно ведь и ядро и приложения будут его использовать. Только придётся ещё в обязательном порядке грузить эту библиотеку.