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

Applications development, KoOS API questions
  • :?: ... null.
    Если уж на то пошло, в новых функциях я планирую немного сменить формат: сначала указатель на строку (dword), а если он равен нулю, то после него непосредственная строка. А то diamond как-то криво сделал.
    0CodErr wrote:...и даже больше, вот и посчитай насколько это медленнее будет
    :roll: А зачем это надо? Пример можешь привести?
  • Spoiler:
    Pathoswithin wrote:А то diamond как-то криво сделал.
    Кто бы говорил.
    http://rvb.ru/18vek/krylov/01text/vol3/01fables/085.htm
  • Ray wrote:Кто бы говорил.
    Вот зря. Посмотри код file_system_lfn, найди место где подфункция проверяется на допустимое значение. Структура кода далека от идеала.
  • file_system_lfn я уже переписал, а валидацию давно сделала CleverMouse, вместе с dyndisk_handler. Его код это отдельная тема, в данном случае я имел в виду API viewtopic.php?f=35&t=475&start=29
  • Pathoswithin wrote:
    0CodErr wrote:...и даже больше, вот и посчитай насколько это медленнее будет
    :roll: А зачем это надо? Пример можешь привести?
    Что зачем надо? Чтобы сравнить скорость обработки UTF8 и UTF16, например. Или опять дурачка включаешь?
    Вот хочу я, к примеру, обрабатывать 100 Гб в час. 1 миллиард символов ASCII это примемрно 1 Гб, просто, чтобы было понятно сколько это. Тогда за сутки это будет более 2-ух Тб. Вот и считай, какие будут каждый день накладные расходы на каждый символ в случае UTF8.
    Вообще, как я уже писал выше, можно проверять, не выходит ли UTF16 строка за рамки UCS2, и, если нет, то обработка будет куда быстрее(так как 2 байта на символ). В подавляющем большинстве случаев будет вполне достаточно UCS2.

    А что насчёт тебя?
    0CodErr wrote:
    Pathoswithin wrote:иметь дело с разными кодировками одновременно
    А зачем это надо? Пример можешь привести?
  • 0CodErr wrote:Что зачем надо? Чтобы сравнить скорость обработки UTF8 и UTF16, например. Или опять дурачка включаешь?
    Вот хочу я, к примеру, обрабатывать 100 Гб в час. 1 миллиард символов ASCII это примемрно 1 Гб, просто, чтобы было понятно сколько это. Тогда за сутки это будет более 2-ух Тб. Вот и считай, какие будут каждый день накладные расходы на каждый символ в случае UTF8.
    Вообще, как я уже писал выше, можно проверять, не выходит ли UTF16 строка за рамки UCS2, и, если нет, то обработка будет куда быстрее(так как 2 байта на символ). В подавляющем большинстве случаев будет вполне достаточно UCS2.
    Ты теоретизируешь - сделай бенчмарк и потести, что будет быстрее - UTF8 или 16.

    IMHO, UCS2 была бы быстрее, но если нужно обрабатывать кодепойнты, то разницы не будет.
    А как замена ASCII, UTF8 идеальна.
  • Siemargl, это было логично делать в unix-ах, где было уже полно работающего софта. У нас этого софта 1,5 программы. Смысла мало.
    Siemargl wrote:IMHO, UCS2 была бы быстрее,
    Да, я как раз об этом. В основном изменения будут касаться файловых функций. Вот у нас там так

    Code: Select all

      * +8: dword: encoding:
        * 0 = cp866 -> byte per char
        * 1 = UTF-16LE -> word per char
    word per char намекает, что работать можно как с UCS2.
    Siemargl wrote:Ты теоретизируешь - сделай бенчмарк и потести, что будет быстрее - UTF8 или 16.
    Всё придумано до нас :) Достаточно погуглить. Обычно говорят, что UTF-8 и EBCDIC более подходит для передачи по сети из-за endianness. Но для обработки внутри программы советуют UCS2/UTF-16/UTF-32.

    Вот ещё есть https://en.wikipedia.org/wiki/Compariso ... _encodings
  • Вот хочу я, к примеру, обрабатывать 100 Гб в час.
    *facepalm* Опять флудера включаешь?
    А что насчёт тебя?
    Вот хочу я, к примеру, чтоб пути к файлам были в UTF-16, из сети получать что-то в UTF-8, а статические текстовые строки в ср866.
  • Pathoswithin wrote:
    Вот хочу я, к примеру, обрабатывать 100 Гб в час.
    *facepalm* Опять флудера включаешь?
    Ты узко мыслишь просто. Иди дальше играй в игрушки :)
    Pathoswithin wrote:Вот хочу я, к примеру, чтоб пути к файлам были в UTF-16, из сети получать что-то в UTF-8, а статические текстовые строки в ср866.
    Ты таки хочешь перемешать всё в кучу? :lol: Хотя это и плохая идея, но и этому ничего не мешает. Да, системный вызов добавится в этом случае. И я тебе приводил пример как это делается в одном месте

    Code: Select all

    function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryW';
    А потом просто везде используют эту юникодную GetCurrentDirectory.
    А ты, вероятно, собираешься делать как-то так

    Code: Select all

    call GetCurrentDirectoryA
    ..........................
    call GetCurrentDirectoryW
    ..........................
    call GetCurrentDirectoryA
    ..........................
    call GetCurrentDirectoryW
    ..........................
    call GetCurrentDirectoryA
    ..........................
    call GetCurrentDirectoryW
    Такое тоже возможно, но это плохая идея. Обычно работает себе программа в юникоде и работает. Нет нужды часто переключаться.
  • Pathoswithin wrote:Если уж на то пошло, в новых функциях я планирую немного сменить формат: сначала указатель на строку (dword), а если он равен нулю, то после него непосредственная строка.
    Ну если всё равно будут новые функции, то можно и параметром передавать. А если он 0, то тогда имя в структуре. Хотя, может, привычнее всё в структуре размещать. Ещё идея: вместо ebx использовать ecx или edx, чтобы не делать лишний раз push\pop в обёртках.
  • Так, вам осталось сделать свой вклад - выбрать номера двух новых функций для UTF-8 и UTF-16 (например 80 или 32).
  • Как насчет 80 и 90? :)
    Из хаоса в космос
  • Ну предлагайте конкретней, какую куда?

    P.S. Решения от фонаря мне даются труднее всего.
  • Pathoswithin, ты про клоны SysFn70? А как же остальное? Или там подфункции будут?
    Ну пусть SysFn80 будет. Можно же указывать encoding в регистре. Например, для UTF16 edx = 1, а для UTF8 edx = 2.
  • Who is online

    Users browsing this forum: No registered users and 9 guests