Board.KolibriOS.org

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

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

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

0CodErr wrote:ОДИН раз ты переключился, и дальше работаешь в юникоде. Если когда-нибудь захотел обратно в ASCII, то также только ОДИН раз вызываешь.

И весь этот геморрой с переключением только ради файловых функций. Вангую массу вопросов от новичков почему у них крякозябры в заголовке окна, в BOARD и т.п.

Pathoswithin
Да, всё начало вырождаться в пустой трёп. Моё мнение:
1. Путь в приложение передавать в utf-8. Предупредить о проблемах с именами директорий в русской кодировке.
2. Добавить utf-8 подфункции к ф.70 и ф.30. Никаких ASCII/UNICODE режимов приложения в ядре не городить.

Согласен с Serge. Где можно, новые подфункции в utf8, где нельзя - только utf8. Минимум несовместимостей, даи потом проще будет убирать устаревший ascii из ядра.

На самом деле делать подфункции к ф.70 не желательно, так как параметр передаётся в структуре и редактировать его нельзя. Я планирую сделать две копии ф.70: для UTF-8 и UTF-16. Одна из них будет 80, а другая - 79, 81 или 32. Выбирайте.
Остальное ограничится новыми подфункциями.

Serge wrote:Ты, образно говоря, предлагаешь дать возможность одному потоку в многопоточном приложении считать в миллиметрах, а другому в дюймах. Это ещё один способ выстрелить себе в ногу.

Ну это ты уже из пальца проблему высосал. Так как, это отнюдь не мешает устанавливать различные маски событий(event_mask) или режим ввода с клавиатуры(keyboard_mode), например.

Serge wrote:Вангую массу вопросов от новичков почему у них крякозябры в заголовке окна, в BOARD и т.п.

Ровно такие же кракозябры, как и в первом сообщении этой темы. Вообще, таких переключений может и не быть: сначала encoding устанавливается в заголовке приложения, затем, если приложение грузит библиотеки, то там нужно ASCII, также, возможно, при обработке CmdLine. Всё! Больше переключаться не нужно!

Pathoswithin wrote:Я планирую сделать две копии ф.70: для UTF-8 и UTF-16.

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

Но лучше уж хотя бы так. Только ещё надо будет GetAppPath и GetCommandLine сделать для разных кодировок. Если, конечно, не планируется использовать поле encoding в заголовке.
UTF-8 это прежде всего тормоза. Очень странно хотеть её использовать в такой системе, как KolibriOS. Она и была разработана ради совместимости с ASCII, но только в KolibriOS нет такой проблемы в силу отсутствия большого количества приложений, нуждающихся в такой совместимости. Так что, такую кодировку стоит использовать просто как ещё одну, не более.

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

Так как, это отнюдь не мешает устанавливать различные маски событий(event_mask) или режим ввода с клавиатуры(keyboard_mode), например.

Тяжёлое наследство тёмного прошлого. Хотя в различных масках событий может быть смысл.

Serge wrote:в различных масках событий может быть смысл.

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

Ты не поверишь, но всё это займёт в ядре несколько десятков байт.
Как UTF-8 связана с тормозами (даже не учитывая скорость работы дисковой системы)? В UNIX это основная кодировка.

Тем не менее индивидуальные маски событий не оправдывают индивидуальны режимы кодировки. Кстати, некоторые длл могут создавать свои потоки. Например console. В этом случае индивидуальные режимы ascii/unicode сделают всё ещё запутанней.

Pathoswithin wrote:Ты не поверишь, но всё это займёт в ядре несколько десятков байт.

Добавление только одной функции займёт ещё меньше.

Pathoswithin wrote:Как UTF-8 связана с тормозами (даже не учитывая скорость работы дисковой системы)? В UNIX это основная кодировка.

Как я писал уже выше, во всех строковых функциях потребуется больше проверок, так как символ может быть представлен 1|2|3|4 байтами. В то время как UTF-16 2|4, UTF-32 4, а ASCII 1. Вот и выходит, что UTF-8 самая тормозная из них.
Да, и у нас вовсе не UNIX. Нет смысла равняться на это. Если тебе нужен UNIX, бери UNIX и используй его в своих целях.

Serge wrote:Тем не менее индивидуальные маски событий не оправдывают индивидуальны режимы кодировки.

Конкретика?

Serge wrote:В этом случае индивидуальные режимы ascii/unicode сделают всё ещё запутанней.

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

Копеечные расходы тормозами не называются.
Вообще-то я сейчас как раз POSIX ублажаю. Если тебе не нужен UNIX, то чем тебе маркеры не нравятся? Тоже вполне чёткий стандарт.

Pathoswithin wrote:Если тебе не нужен UNIX, то чем тебе маркеры не нравятся?

А зачем их лепить к каждой строке, если можно проверить только APPDATA.Encoding?

Pathoswithin wrote:Копеечные расходы тормозами не называются.

Только здесь не про копеечные речь. Дополнительные проверки на каждый символ.

А затем, что с таким стандартом можно было бы иметь дело с разными кодировками одновременно, но вообще не задумываться об этом.

Ты собираешься проверять миллиард символов?

Pathoswithin wrote:иметь дело с разными кодировками одновременно

А зачем это надо? Пример можешь привести?

Pathoswithin wrote:Ты собираешься проверять миллиард символов?

...и даже больше, вот и посчитай насколько это медленнее будет