Странности с Copy

Вопросы программирования и использования среды Lazarus.

Модератор: Модераторы

Re: Странности с Copy

Сообщение alexs » 04.09.2018 09:08:48

Cheb писал(а):Как только что-нибудь нетривиальное, где надо елозить взад-вперёд - Здравствуй. Опа. Новый год.

А вот для таких частных случаев и нужны мозги программера :-)
На самом деле универсальных решений не существует. Надо смотреть в каждой ситуации отдельно.
А по вопросу топикстартера - скорее всего ему хватит заменить Copy на UTF8Copy
Аватара пользователя
alexs
долгожитель
 
Сообщения: 3675
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Re: Странности с Copy

Сообщение Снег Север » 04.09.2018 20:54:21

Vadim писал(а):Снег Север
А есть уже готовые алгоритмы тестов. Именно тестов, чтобы было видно время исполнения?
Не знаю, у меня нету.
Аватара пользователя
Снег Север
энтузиаст
 
Сообщения: 1177
Зарегистрирован: 27.11.2007 16:14:47

Re: Странности с Copy

Сообщение Cheb » 05.09.2018 14:49:59

Для чего удобнее? Повторюсь, каков практический смысл?

Пример: мой компилятор сайта с фанфиками (недо- CMS, фактически). Синтакс исходников - не по науке, а как удобнее автору в ворде текст романа оформлять.
В результате - парсинг вдоль строки поминутно лазит проверять, какой был предыдущий символ или какие следующие символы.

Тут и тестов не нужно.
Посмотрел исходники utf8copy. Естественно, она проходит по всей строке вплоть до указанного места чтобы найти его истинную позицию.
Иии, переведённый с юникода в utf-8 парсинг плавно превращается из O*N в O*N^2.
Дружественность к кешу? Не, не слышали.

В моём случае, сотни строк (один файл - одна глава), каждая в десятки килобайт, и COPY() там вызывалась бы на каждый символ - в то время, как сейчас я в большинстве случаев обращаюсь к букве как к элементу массива по индексу.

ЛИБО ЖЕ надо всё это безобразие учитывать, первым проходом строя массив позиций и длин всех утф-8 символов, а потом адресуясь по нему при каждой copy, что внесло бы дополнительные баги и снизило наглядность кода. А у меня парсер, натыкаясь на директиву {$include, ещё правит рельсы впереди паровоза - т.е. врезает содержимое файла в строку не прерывая процесса. И приходилось бы это учитывать и 100500 раз перестраивать таблицу адресов символов.

..короче, работая с многобайтовой кодировкой, вы не работаете, а трахаетесь с её изысками. Это НЕ формат для обработки.

Это не говоря уже, что это всё LazUtf8, в чистом фри паскале этих функций нет.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 684
Зарегистрирован: 06.06.2005 15:54:34

Re: Странности с Copy

Сообщение zoltanleo » 05.09.2018 15:42:59

Cheb писал(а):Пример

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

В твоем случае я бы заменил стандартную на самописную.
Аватара пользователя
zoltanleo
постоялец
 
Сообщения: 198
Зарегистрирован: 17.10.2013 10:55:01

Re: Странности с Copy

Сообщение Cheb » 06.09.2018 09:39:16

А зачем, если UnicodeString работает БЕЗ геморроя и БЕЗ необходимости подстраивать свои алгоритмы? Она безопасная, её поведение идентично между fpc 2.6.4 и fpc 3.x, никаких подводных камней с неявными перекодировками. Одни плюсы. И для русского текста, как я уже говорил, никакой разницы в объёме потребляемой памяти.

Оставьте utf-8 сишникам и тем людям, которые любят трахаться, а не дело делать.

JavaScript - который я считаю образцовым языком (за вычитом некоторых вывихов, да), использует UTF-16 во внутреннем представлении строк. К тому же, он несколько быстрее фри паскаля при работе со строками.

..хотя, конечно, самым правильным было бы использовать UTF-32..

P.S. Короче, моё мнение насчёт UTF-8:
- использование её для хранения и обмена - замечательная идея просто потому, что это стандартизация, которая аццки удобна
- использование её вообще везде-везде-везде - из оперы "заставь дурака богу молиться".
Каждый инструмент хорош на своём месте. Не надо забивать гвозди перфоратором.

P.P.S. Я в своём движке давно все файлы конфигурации перевёл в утф-8. А некоторое время назад - добавил два патча, для фпц 2.6.4 и фпц 3.0, которые делают работу с файлами в виндовс через утф-8.
Но вся работа со строками (за исключением исходников GLSL программ) - только UnicodeString.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 684
Зарегистрирован: 06.06.2005 15:54:34

Re: Странности с Copy

Сообщение zoltanleo » 06.09.2018 11:55:26

Cheb писал(а):..хотя, конечно, самым правильным было бы использовать UTF-32..

ИМХО, с практической точки зрения для русского языка нет никакой разницы между UTF8-16-32: в каждой из них 1 символ кодируется более 1 байтом, что и приходится учитывать при парсинге строк. Главное, чтобы на любой платформе вместо кракозябров всегда отображались желаемые символы.

И еще, НЕиспользование стандартных функций Лазаря не является критерием True-программиста :wink:
Аватара пользователя
zoltanleo
постоялец
 
Сообщения: 198
Зарегистрирован: 17.10.2013 10:55:01

Re: Странности с Copy

Сообщение Cheb » 06.09.2018 20:17:22

Значит, я не в ту ветку зашёл :D
Предпочитаю делать программы, которые не используют лазарус, или используют лазарус в качестве удобного запускатора с кнопкой выбора файлов и прокручиваемым TMemo журнала - а сам код, который выполняет всю работу, 100% лазаренезависимый.

не является критерием True-программиста

Критерием настоящего программиста является понимание работы инструментов и использование подходящих.
Utf8Copy - это костыль. Годится для портировать по быстрому, в этом плане полезна, но вести разработку новых вещей на ней - значит использовать O*N^2 вместо O*N - непростительное транжирство.

А потом удивляться будут, почему жаваскрипт вокруг паскаля круги нарезает, как вокруг стоячего.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 684
Зарегистрирован: 06.06.2005 15:54:34

Пред.

Вернуться в Lazarus

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8

Рейтинг@Mail.ru