Путь приложения

Applications development, KoOS API questions
  • 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:Ты, образно говоря, предлагаешь дать возможность одному потоку в многопоточном приложении считать в миллиметрах, а другому в дюймах. Это ещё один способ выстрелить себе в ногу.
    Ну это ты уже из пальца проблему высосал. :lol: Так как, это отнюдь не мешает устанавливать различные маски событий(event_mask) или режим ввода с клавиатуры(keyboard_mode), например.
    Serge wrote:Вангую массу вопросов от новичков почему у них крякозябры в заголовке окна, в BOARD и т.п.
    Ровно такие же кракозябры, как и в первом сообщении этой темы. Вообще, таких переключений может и не быть: сначала encoding устанавливается в заголовке приложения, затем, если приложение грузит библиотеки, то там нужно ASCII, также, возможно, при обработке CmdLine. Всё! Больше переключаться не нужно!
    Pathoswithin wrote:Я планирую сделать две копии ф.70: для UTF-8 и UTF-16.
    Serge wrote:Ядро не безразмерно.
    :mrgreen: Но лучше уж хотя бы так. Только ещё надо будет GetAppPath и GetCommandLine сделать для разных кодировок. Если, конечно, не планируется использовать поле encoding в заголовке.
    UTF-8 это прежде всего тормоза. Очень странно хотеть её использовать в такой системе, как KolibriOS. Она и была разработана ради совместимости с ASCII, но только в KolibriOS нет такой проблемы в силу отсутствия большого количества приложений, нуждающихся в такой совместимости. Так что, такую кодировку стоит использовать просто как ещё одну, не более.

    Как я понял, вместо добавления одной сисфункции для переключения кодировки будут продублированы все. Ну что ж, так, конечно, лучше, ведь это не раздует ядро :lol: :mrgreen: Сами себе противоречите!
  • Так как, это отнюдь не мешает устанавливать различные маски событий(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:Ты собираешься проверять миллиард символов?
    ...и даже больше, вот и посчитай насколько это медленнее будет
  • Who is online

    Users browsing this forum: No registered users and 9 guests