Путь приложения
-
Что, кстати, насчёт той viewtopic.php?f=38&t=1277&start=600#p67688 идеи? Ну пусть это будет не кавычка, пусть слэш будет.
... null.
Если уж на то пошло, в новых функциях я планирую немного сменить формат: сначала указатель на строку (dword), а если он равен нулю, то после него непосредственная строка. А то diamond как-то криво сделал.
Если уж на то пошло, в новых функциях я планирую немного сменить формат: сначала указатель на строку (dword), а если он равен нулю, то после него непосредственная строка. А то diamond как-то криво сделал.
А зачем это надо? Пример можешь привести?0CodErr wrote:...и даже больше, вот и посчитай насколько это медленнее будет
Spoiler:
Кто бы говорил.Pathoswithin wrote:А то diamond как-то криво сделал.
http://rvb.ru/18vek/krylov/01text/vol3/01fables/085.htm
Вот зря. Посмотри код file_system_lfn, найди место где подфункция проверяется на допустимое значение. Структура кода далека от идеала.Ray wrote:Кто бы говорил.
file_system_lfn я уже переписал, а валидацию давно сделала CleverMouse, вместе с dyndisk_handler. Его код это отдельная тема, в данном случае я имел в виду API viewtopic.php?f=35&t=475&start=29
Что зачем надо? Чтобы сравнить скорость обработки UTF8 и UTF16, например. Или опять дурачка включаешь?Pathoswithin wrote:А зачем это надо? Пример можешь привести?0CodErr wrote:...и даже больше, вот и посчитай насколько это медленнее будет
Вот хочу я, к примеру, обрабатывать 100 Гб в час. 1 миллиард символов ASCII это примемрно 1 Гб, просто, чтобы было понятно сколько это. Тогда за сутки это будет более 2-ух Тб. Вот и считай, какие будут каждый день накладные расходы на каждый символ в случае UTF8.
Вообще, как я уже писал выше, можно проверять, не выходит ли UTF16 строка за рамки UCS2, и, если нет, то обработка будет куда быстрее(так как 2 байта на символ). В подавляющем большинстве случаев будет вполне достаточно UCS2.
А что насчёт тебя?
0CodErr wrote:А зачем это надо? Пример можешь привести?Pathoswithin wrote:иметь дело с разными кодировками одновременно
Ты теоретизируешь - сделай бенчмарк и потести, что будет быстрее - UTF8 или 16.0CodErr wrote:Что зачем надо? Чтобы сравнить скорость обработки UTF8 и UTF16, например. Или опять дурачка включаешь?
Вот хочу я, к примеру, обрабатывать 100 Гб в час. 1 миллиард символов ASCII это примемрно 1 Гб, просто, чтобы было понятно сколько это. Тогда за сутки это будет более 2-ух Тб. Вот и считай, какие будут каждый день накладные расходы на каждый символ в случае UTF8.
Вообще, как я уже писал выше, можно проверять, не выходит ли UTF16 строка за рамки UCS2, и, если нет, то обработка будет куда быстрее(так как 2 байта на символ). В подавляющем большинстве случаев будет вполне достаточно UCS2.
IMHO, UCS2 была бы быстрее, но если нужно обрабатывать кодепойнты, то разницы не будет.
А как замена ASCII, UTF8 идеальна.
Siemargl, это было логично делать в unix-ах, где было уже полно работающего софта. У нас этого софта 1,5 программы. Смысла мало.
word per char намекает, что работать можно как с UCS2.
Вот ещё есть https://en.wikipedia.org/wiki/Compariso ... _encodings
Да, я как раз об этом. В основном изменения будут касаться файловых функций. Вот у нас там такSiemargl wrote:IMHO, UCS2 была бы быстрее,
Code: Select all
* +8: dword: encoding:
* 0 = cp866 -> byte per char
* 1 = UTF-16LE -> word per char
Всё придумано до нас Достаточно погуглить. Обычно говорят, что UTF-8 и EBCDIC более подходит для передачи по сети из-за endianness. Но для обработки внутри программы советуют UCS2/UTF-16/UTF-32.Siemargl wrote:Ты теоретизируешь - сделай бенчмарк и потести, что будет быстрее - UTF8 или 16.
Вот ещё есть https://en.wikipedia.org/wiki/Compariso ... _encodings
*facepalm* Опять флудера включаешь?Вот хочу я, к примеру, обрабатывать 100 Гб в час.
Вот хочу я, к примеру, чтоб пути к файлам были в UTF-16, из сети получать что-то в UTF-8, а статические текстовые строки в ср866.А что насчёт тебя?
Ты узко мыслишь просто. Иди дальше играй в игрушкиPathoswithin wrote:*facepalm* Опять флудера включаешь?Вот хочу я, к примеру, обрабатывать 100 Гб в час.
Ты таки хочешь перемешать всё в кучу? Хотя это и плохая идея, но и этому ничего не мешает. Да, системный вызов добавится в этом случае. И я тебе приводил пример как это делается в одном местеPathoswithin wrote:Вот хочу я, к примеру, чтоб пути к файлам были в UTF-16, из сети получать что-то в UTF-8, а статические текстовые строки в ср866.
Code: Select all
function GetCurrentDirectory; external kernel32 name 'GetCurrentDirectoryW';
А ты, вероятно, собираешься делать как-то так
Code: Select all
call GetCurrentDirectoryA
..........................
call GetCurrentDirectoryW
..........................
call GetCurrentDirectoryA
..........................
call GetCurrentDirectoryW
..........................
call GetCurrentDirectoryA
..........................
call GetCurrentDirectoryW
Ну если всё равно будут новые функции, то можно и параметром передавать. А если он 0, то тогда имя в структуре. Хотя, может, привычнее всё в структуре размещать. Ещё идея: вместо ebx использовать ecx или edx, чтобы не делать лишний раз push\pop в обёртках.Pathoswithin wrote:Если уж на то пошло, в новых функциях я планирую немного сменить формат: сначала указатель на строку (dword), а если он равен нулю, то после него непосредственная строка.
Так, вам осталось сделать свой вклад - выбрать номера двух новых функций для UTF-8 и UTF-16 (например 80 или 32).
Как насчет 80 и 90?
Из хаоса в космос
Ну предлагайте конкретней, какую куда?
P.S. Решения от фонаря мне даются труднее всего.
P.S. Решения от фонаря мне даются труднее всего.
Pathoswithin, ты про клоны SysFn70? А как же остальное? Или там подфункции будут?
Ну пусть SysFn80 будет. Можно же указывать encoding в регистре. Например, для UTF16 edx = 1, а для UTF8 edx = 2.
Ну пусть SysFn80 будет. Можно же указывать encoding в регистре. Например, для UTF16 edx = 1, а для UTF8 edx = 2.
Who is online
Users browsing this forum: No registered users and 2 guests