xor eax,eax ;флаг результата. Если 0 — строки НЕ равны
mov esi,offset string1
mov edi,offset string2
repe cmpsb
jne done
inc eax ;флаг результата = 1, строки равны
done:
;если Eax = 0 — строки не равны, если 1 — равны.
До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?
L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?
До сих пор не используешь Unicode для своих строк? А то в них нулевой байт может появиться в самом неожиданном месте.
L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?
... и чтобы отработало за константное число тактов
L>>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат? B>До сих пор не используешь Unicode для своих строк? А то в них нулевой байт может появиться в самом неожиданном месте.
UTF16/32 не нужны
Как много веселых ребят, и все делают велосипед...
L>repe cmpsb L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?
Здравствуйте, nekocoder, Вы писали:
N>Здравствуйте, bzig, Вы писали:
B>>До сих пор не используешь Unicode для своих строк? А то в них нулевой байт может появиться в самом неожиданном месте.
N>В UTF-8 не может
Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
N>>В UTF-8 не может
B>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
UTF-8 совместим со старым софтом и протоколами, потому что в такой строке не может встретиться байт 0x00, который бы ее обрывал.
Здравствуйте, lamai, Вы писали:
B>>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
L>UTF-8 совместим со старым софтом и протоколами, потому что в такой строке не может встретиться байт 0x00, который бы ее обрывал.
Ни в "старом софте и протоколах", ни в новых нет никакого обязательного правила, что NUL не может встречаться в теле текстовой строки. Это абсолютно рядовой управляющий символ. Если считаете иначе — покажите соответствующий стандарт среди тех же издателей, что выдали ASCII с компанией, то есть ECMA, ISO, IEC. Вангую: ничего такого не найдёте.
Особая роль кода 0 является специфическим дополнением API Unix и родственных систем. И в Unix оно не является универсальным: большинство современных утилит, работающих с текстами (как sed, awk, sort, редакторы типа vim) адаптированы на поддержку NUL как обычного кода. POSIX хранит разрешение на ограничение "NUL не может быть в текстовой строке" для легаси, но не запрещает расширять реализации на его поддержку. Большинство утилит GNU (типа sed, awk, sort), средств скриптования вроде Perl, Python не запрещают NUL в строках или текстовом вводе-выводе.
В C++ основным средством представления текста является std::string, которая явно хранит длину данных и не запрещает NUL в них. Все интерфейсы адаптированы на использование длины там, где она известна. Начиная с C++17 есть std::string_view, который помогает обеспечивать то же самое для строковых литералов. Использование интерфейсов libc, которые вместо явной длины строки ищут NUL, ограничено относительно короткими строками, страдает проблемами маляра Шлёмиэля и в современных рекомендациях исключается, кроме тех мест, где длина строки неизвестна из-за свойств её источника.
Тенденция к отказу от API с NUL-terminated строками является известным свойством последних 30 лет, если не больше. Где вы провели всё это время — непонятно, но пора выползать из таёжного схрона.
N>>В UTF-8 не может B>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
не может, а еще слэш не может (за исключением когда слэш — это слэш) и много чего еще. Благодаря чему ядро лялиха поддерживает UTF8 в файловых системах даже не задумываясь об этом (в отличии от ядра винды, которая case insensitive и потому всегда думает над UTF16).
Какие байты могут быть в UTF8 строки написано тут https://en.wikipedia.org/wiki/UTF-8#Description — у всех многобайтных последовательностей установлен как минимум старший бит в каждом байте. А однобайтные символы — это ASCII
Как много веселых ребят, и все делают велосипед...
L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?
а где в твоем примере цикл ? Ты именно что выполняешь одну команду (cmpsb) и получаешь результат (zf).
N>В C++ основным средством представления текста является std::string, которая явно хранит длину данных и не запрещает NUL в них. Все интерфейсы адаптированы на использование длины там, где она известна. Начиная с C++17 есть std::string_view, который помогает обеспечивать то же самое для строковых литералов.
это не отменяет факта наличия функции std::string::c_str
N>Тенденция к отказу от API с NUL-terminated строками является известным свойством последних 30 лет, если не больше. Где вы провели всё это время — непонятно, но пора выползать из таёжного схрона.
хз. сишные API как-то не часто кроме чаров еще и длину (не как капасити) принимают
B>>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё. O>не может,
может
O>а еще слэш не может (за исключением когда слэш — это слэш) и много чего еще.
шта
O>Благодаря чему ядро лялиха поддерживает UTF8 в файловых системах даже не задумываясь об этом
еще как задумываясь
O>(в отличии от ядра винды, которая case insensitive и потому всегда думает над UTF16).
В винде проблемы не из-за этого.
O>Какие байты могут быть в UTF8 строки написано тут https://en.wikipedia.org/wiki/UTF-8#Description — у всех многобайтных последовательностей установлен как минимум старший бит в каждом байте. А однобайтные символы — это ASCII
0x0 — это тоже однобайтный символ. И в валидной UTF-8 последовательности он может быть в любом месте. Поэтому некоторые системы используют модифицированный UTF-8, чтобы избежать собственных ограничений, что является security-risk'ом и об этом напрямую говорится в RFC 3629
M>>0x0 — это тоже однобайтный символ. O>вот именно, однобайтный символ из сабсета символов, эквивалентных ASCII.
Еще раз. Медленно:
В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
И это справедливо для UTF-8 тоже. Просто в кодировке UTF-8 (одной из возможных кодировок):
Character numbers from U+0000 to U+007F (US-ASCII repertoire)
correspond to octets 00 to 7F (7 bit US-ASCII values). A direct
consequence is that a plain ASCII string is also a valid UTF-8
string.
То есть:
— plain ASCII string является валидной строкой в UTF-8
— обратное неверно в общем случае
M>В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
Ну, покажи как выглядит этот NUL символ в печати и к какой локали он соответствует? Так то и в ASCII 0 — это просто NUL символ. Но он никому не нужен ни для чего, кроме как индицировать конец строки. Точно так же и в юникод строках. Хотя либители паскаля и UNICODE_STRING могут хранить в нем соленые огурчики, конечно)
Как много веселых ребят, и все делают велосипед...
O>Ну, покажи как выглядит этот NUL символ в печати и к какой локали он соответствует?
юникод не имеет отношения к печати
O>Так то и в ASCII 0 — это просто NUL символ. Но он никому не нужен ни для чего, кроме как индицировать конец строки.
В ASCII и в системах с null-terminated строками — да. Но:
— строки не обязательно должны быть null-terminated
— NUL не означает завершение строки в юникоде
— юникодная строка является валидной даже если NUL встречается в ней в середине
— это справедливо для всех юникодных кодировок, включая UTF-8
Поэтому некоторые системы используют модифицированный UTF-8, чтобы избежать собственных ограничений, что является security-risk'ом и об этом напрямую говорится в RFC 3629.
Еще раз: в ASCII символ с кодом 0 — это просто null символ: http://www.asciitable.com/
И в середине ASCII строки символ с кодом 0 тоже может быть, ктож помешает
То что строки в C являются NULL-terminated — это соглашение на уровне ЯП, а не на уровне кодировки. NULL-terminated строки в кодировке ASCII. NULL-terminated строки в кодировке KOI8. NULL-terminated строки в кодировке CP1251. Точно так же может быть NULL-terminated в кодировке UTF8/UTF16/UTF32. За небольшим дополнением что размер codepoint unit в UTF8 равен 1, а в UTF16 — два, а в UTF32 — четыре. И потому NULL-character в UTF8 — это просто байт 0, как и в "простых" однобайтных кодировках. А в UTF16 — это два байта 0 (на четной позиции). А в UTF32 — четыре нулевых байта.
В свою очередь алгоритм кодирования многобайтных символов в UTF8 устроен так, что ни один многобайтный символ не может содержать в себе нулевой байт. А значит нулевой байт в UTF8 однозначно является NUL character'ом. В отличии от UTF16/32 где NUL character'ом является лишь нулевой codepoint unit, а нулевые байты могут быть частью ненулевых codepoint unit-ов.
Как много веселых ребят, и все делают велосипед...