Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Нужен нормальный текстовый редактор
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Russian
View previous topic :: View next topic  
Author Message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Sun Mar 12, 2006 10:15 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

lefsha wrote:

Специально для Вас! Открываем консоль виндовс и пишем слово "Привет"
на трех языках, русском, немецком и китайском и далее поражаемся своей крутизне
если видим все три слова. В противном случае успокаиваемся и перестаем
нести ерунду.

В виндовс нет понятия консолив принципе =) Есть понятие command shell - штука, оставленная для совместимости с DOS, и для более удобного выполняния некоторых административных задач (GUI - не панацея, как и ООП, к примеру). И по понятным причинам этот самый шелл знать не знает про юникод - иделогия у него такая, _legacy_.
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Sun Mar 12, 2006 10:25 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

Balancer wrote:
> Важно лишь, что в винде никода не было бардака с 10-ком русских кодировок (а была либо CP1251, она же рус. ANSI, или UNICODE)

И давно консоль в Windows начала в 1251 работать? :)
Code:

dir > dirlist.txt

В какой кодировке будет?

А то, что банальный ноутпад уже сегодня предлагает сохранять документы в UTF-8 (не говоря уже про Office) говорит о том, что _сегодня_ для успешного функционирования Windows требуются, как минимум, три кодировки: 1251, 866 и utf-8.

В то время, как мой Gentoo работает исключительно с UTF-8 :D И даже в худшие времена под Linux редко вставал вопрос выбора из более, чем двух кодировок: koi8-r против 1251 или koi8-r против utf-8 :)


UTF-8, кстати, в винде нигде не используется. Данная кодировка удобна для передачи служебных данных, хранения XML. Но любые операции со строками в UTF-8 - это мучительно и долго. Про отладку я вообще молчу.

Balancer wrote:
>Открываем консоль виндовс и пишем слово "Привет" на трех языках

Нормальные люди, мне казалось, должны знать, что консольный command.com - неюникодный. В частности, у подавляющего большинства тут присутствующих, он должен быть с cp866. И он не может иметь иную кодировку из соображений совместимости. DOS-программы никто не отменял.

А вот том же банальном ноутпаде можно хоть на десяти языках написать.


Вот вы сами себе и ответили - почему в виндах живет до 3-х кодировок:
- CP866 и иже с ней в cmd.exe - для совместимости с досом и командными сценариями
- CP1251 и иже с ней - для поддержки приворуких программистов, ненавидящих юникод всей душой (в линуксе, кстати, если автор программы слышал только про кои8 - прийдется поработать ручками. а тут из коробки все ок)
- Юникод (UTF-16) - как основная кодировка системы, в ней работает ядро, прикладные программы, файловая система.
Back to top
View user's profile Send private message
lefsha
Veteran
Veteran


Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria

PostPosted: Sun Mar 12, 2006 7:07 pm    Post subject: Reply with quote

Balancer wrote:
>Открываем консоль виндовс и пишем слово "Привет" на трех языках

Нормальные люди, мне казалось, должны знать, что консольный command.com - неюникодный. В частности, у подавляющего большинства тут присутствующих, он должен быть с cp866. И он не может иметь иную кодировку из соображений совместимости. DOS-программы никто не отменял.

А вот том же банальном ноутпаде можно хоть на десяти языках написать.


Нормальные люди должны знать, что если система не поддерживает
Уникод частично, значит она его не поддерживает.
Кроме того никто никому не запрещал сделать нормальную консоль.

Кроме того было достаточно проблем с файлами, которые по причине
кривости имени нельзя было удалить никак...
Я к счастью уже давно не имею возможности это продемонстрировать.
_________________
Lefsha
Back to top
View user's profile Send private message
Balancer
Guru
Guru


Joined: 04 Jun 2004
Posts: 465

PostPosted: Sun Mar 12, 2006 9:31 pm    Post subject: Reply with quote

>Кроме того было достаточно проблем с файлами, которые по причине
кривости имени нельзя было удалить никак...

Остаётся только удивится, почему я в бытность работы с виндой, имея файлы и тексты на арабском, русском, немецком языках таких проблем не имел :D Наверное, это не имена кривые были, а что-то другое у кого-то другого... :)

...

Но, если рассуждать по твоему, то полностью юникодной системы сейчас нет ни одной. Почитай на этом форуме, сколько проблем с UTF-8 встречает народ. Некоторые - решаются. Для некоторых - есть грязные хаки. Но некоторые - не решены пока в принципе.
Back to top
View user's profile Send private message
lefsha
Veteran
Veteran


Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria

PostPosted: Sun Mar 12, 2006 10:40 pm    Post subject: Reply with quote

Balancer wrote:
>Кроме того было достаточно проблем с файлами, которые по причине
кривости имени нельзя было удалить никак...

Остаётся только удивится, почему я в бытность работы с виндой, имея файлы и тексты на арабском, русском, немецком языках таких проблем не имел :D Наверное, это не имена кривые были, а что-то другое у кого-то другого... :)


Возможно Вы работали на одной машине.
Я же имел проблемы с файлами на разных машинах - разной локализацией,
соединенных в сеть. Если на вашей машине нет данного языка У Вас
получаются проблемы с файлом на другой машине.
Это было в прошлом, так что я не смогу сейчас привести какие либо доказательства.

На счет комплиментов в мой адрес - это обычно признак отсуствия аргументов
или соотвествующего уровня собеседника.

Balancer wrote:

Но, если рассуждать по твоему, то полностью юникодной системы сейчас нет ни одной. Почитай на этом форуме, сколько проблем с UTF-8 встречает народ. Некоторые - решаются. Для некоторых - есть грязные хаки. Но некоторые - не решены пока в принципе.


Пока мне сложно привести примеры проблем с уникодом в Linux.
Если Вы знаете хоть один - приведите его.
_________________
Lefsha
Back to top
View user's profile Send private message
lefsha
Veteran
Veteran


Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria

PostPosted: Sun Mar 12, 2006 10:45 pm    Post subject: Reply with quote

Ладно. Надо завязывать.

Нормального редактора еще не придумали и приходится пользоваться тем что есть.
_________________
Lefsha
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Tue Mar 14, 2006 4:35 pm    Post subject: Reply with quote

lefsha wrote:
Balancer wrote:
>Кроме того было достаточно проблем с файлами, которые по причине
кривости имени нельзя было удалить никак...

Остаётся только удивится, почему я в бытность работы с виндой, имея файлы и тексты на арабском, русском, немецком языках таких проблем не имел :D Наверное, это не имена кривые были, а что-то другое у кого-то другого... :)


Возможно Вы работали на одной машине.
Я же имел проблемы с файлами на разных машинах - разной локализацией,
соединенных в сеть. Если на вашей машине нет данного языка У Вас
получаются проблемы с файлом на другой машине.
Это было в прошлом, так что я не смогу сейчас привести какие либо доказательства.

На счет комплиментов в мой адрес - это обычно признак отсуствия аргументов
или соотвествующего уровня собеседника.

Balancer wrote:

Но, если рассуждать по твоему, то полностью юникодной системы сейчас нет ни одной. Почитай на этом форуме, сколько проблем с UTF-8 встречает народ. Некоторые - решаются. Для некоторых - есть грязные хаки. Но некоторые - не решены пока в принципе.


Пока мне сложно привести примеры проблем с уникодом в Linux.
Если Вы знаете хоть один - приведите его.


Что значит "нет языка"? =) Не установлены шрифты? Не задана локаль для неюникондого софта? А доказательства - их приводить и самом деле - излишне. А то ведь и ламером прослыть можно, а так - пустая критика и ни одной реальной проблемы, за исключением требования "сделать консоль в виндовсе, такую же, как в линухе". Так что про агрументы стоит помалкивать - до тех пор, пока ты сам не начнешь их приводить.

Теперь про проблемы с юникодом в линухе. Да вот они: хелп в MC, крякозябры в GTK-приложениях вроде XMMS (да, виноват xorg - но он де-факто часть ос), сообщения в mplayer - достаточно? Я не говорю про мелкие "затыки" вроде невозможности сделать себе логин "Вася Пупкин" (да, может правкой неких конфигов это и фиксится - но по-умолчанию не работает) =) Также стоит сделать поиск в гугле "utf8 lunux not work" - там очень много интересного. Что самое забавное, аналогичный поиск для винды практически ничего не даст - это или узкоспециальные проблемы, или грабли в старых версиях ПО.

ЗЫ А текстовый редактор я давно нашел, если еще wine оказжется более-менее работоспособным, то жить в линуксе станет возможно.
Back to top
View user's profile Send private message
046
Apprentice
Apprentice


Joined: 21 Jul 2004
Posts: 231
Location: Yaroslavl, Russia

PostPosted: Wed Mar 15, 2006 5:56 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

Koshh wrote:
Но любые операции со строками в UTF-8 - это мучительно и долго. Про отладку я вообще молчу.

Поясни почему это операции со строками в UTF-8 долгие? Это же обычный ascii, и все операции (удаление/вставка/замена) выполняются аналогично!! Опять ерунду пишете!

Какая такая отладка? И почему вообще молчишь? Такой бред что самому смешно?
Back to top
View user's profile Send private message
046
Apprentice
Apprentice


Joined: 21 Jul 2004
Posts: 231
Location: Yaroslavl, Russia

PostPosted: Wed Mar 15, 2006 6:00 am    Post subject: Reply with quote

Koshh wrote:
Теперь про проблемы с юникодом в линухе...
Мухаха. Експлорер файлов это значит левая старая глючная программа, а mc является неотъемлимой частью linux.
Валяюсь под стулом :)
Back to top
View user's profile Send private message
Balancer
Guru
Guru


Joined: 04 Jun 2004
Posts: 465

PostPosted: Wed Mar 15, 2006 11:12 am    Post subject: Reply with quote

046 wrote:
Koshh wrote:
Теперь про проблемы с юникодом в линухе...
Мухаха. Експлорер файлов это значит левая старая глючная программа, а mc является неотъемлимой частью linux.
Валяюсь под стулом :)


Как обычно, комментируем только то, что выгодно? :)
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Thu Mar 16, 2006 5:59 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

046 wrote:
Koshh wrote:
Но любые операции со строками в UTF-8 - это мучительно и долго. Про отладку я вообще молчу.

Поясни почему это операции со строками в UTF-8 долгие? Это же обычный ascii, и все операции (удаление/вставка/замена) выполняются аналогично!! Опять ерунду пишете!

Какая такая отладка? И почему вообще молчишь? Такой бред что самому смешно?

Это не обычный ascii, посколку 1 символ может занимать как 8 бит, так и 16. Первые 127 символов таблицы ascii оставлены "как есть" - англ. буквы, цифры, скобки и т.д. Все остальные символы Unicode - кодируются 16-ю битами (к примеру, последовательность байтов D1 84 кодирует русскую букву 'ф', а 3E - символ '>'). И кодировка эта разрабатывалась скорее как транспортная - налицо уменьшение трафика при передаче HTTP запросов и XML документов (служебные сисволы там как раз из первой половины таблицы ascii). Но любые операции с такими строками требуют сложных алгоритмов - поскольку строку нельзя представить как массив байт или машинных слов (в случае UTF-16). Отсюда - дополнительные накладные расходы при обработке строк. Проблемы с отладкой проистекают хотя бы из того, что длина строки (в байтах) неизвестна до момента прогона программы - переменная длина символа, как-никак =)

Так что ерунду пишешь именно ты, не понимая сути предмета.
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Thu Mar 16, 2006 6:18 am    Post subject: Reply with quote

046 wrote:
Koshh wrote:
Теперь про проблемы с юникодом в линухе...
Мухаха. Експлорер файлов это значит левая старая глючная программа, а mc является неотъемлимой частью linux.
Валяюсь под стулом :)

Никто никогда не называл эексплорере старой и глючной программой, у эксплорера нет никаких проблем с отображением юникодных символов.

Что жекасается MC, то проблема заключается не возрасте или глючности программы, а в том, что программа, замечательно работающая с одними настройками ОС, при переходе на более новые (и прогрессивные) работать отказывается. То есть KOI8 и UTF-8 вещи взаимосключаемые в линухе (пляски с конвертацией справки из одного формата в другой - это не решение, фактически это перекомпиляция программы). А винда 3 кодироваки одновременно есть (см. предидущие посты).
Back to top
View user's profile Send private message
046
Apprentice
Apprentice


Joined: 21 Jul 2004
Posts: 231
Location: Yaroslavl, Russia

PostPosted: Thu Mar 16, 2006 8:48 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

Koshh wrote:
Это не обычный ascii, посколку 1 символ может занимать как 8 бит, так и 16. Первые 127 символов таблицы ascii оставлены "как есть" - англ. буквы, цифры, скобки и т.д. Все остальные символы Unicode - кодируются 16-ю битами (к примеру, последовательность байтов D1 84 кодирует русскую букву 'ф', а 3E - символ '>'). И кодировка эта разрабатывалась скорее как транспортная - налицо уменьшение трафика при передаче HTTP запросов и XML документов (служебные сисволы там как раз из первой половины таблицы ascii).

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

Проблемы с отладкой проистекают хотя бы из того, что длина строки (в байтах) неизвестна до момента прогона программы - переменная длина символа, как-никак =)


Поскольку Вы считаете что я не понимаю, то начну учить :)
1.
В utf-8 символ может кодироваться последовательностью от одного до 6!! октета. (1 октет = 8 бит, практически тоже самое что и байт)
Все символы unicode НЕ ВЛЕЗАЮТ в 16 бит. И utf-8 была создана не для экономии (экономная она только на ASCII тексте), а для совместимости. Куча библиотек (в том числе и ядро linux) работает со строками как с последовательностями, заканчивающимися нулевым байтом. Для этого кодировка utf-8 подходит.

2. Любые данные можно представить как массив байт или машинных слов в памяти. Кстати машины с размером слова в 16 бит уже жуткая редкость :) Переход с 32 на 64 идёт. Да, в utf-8 нельзя в произвольном месте, заменить/вставить/удалить произвольный байт / слово / ещё какою нибудь фигню, не опасаясь, что изменения затронут весь последующий текст. Ознако заменять utf подстроку на utf, а также удалять и добавлять utf подстроки в любом месте можно совершенно свободно.
И это касается всех кодировок с переменным числом байт включая utf-16!
Unicode кодировки с постоянным числом бит (лишённые подобных недостатков) называются ucs (в противовес utf). Например ucs-4, в которой каждый символ кодируется 32 битами.

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


В кодировках с переменным числом байт на символ (включая utf-16), есть недостаток две медленно работающие операции.
1. Количество символов в строке. (в отличии от получения занимаемой строкой памяти, это крайне редкая операция)
2. Получения символа по его позиции. (также редкая операция в отличии от последовательного чтения символов)
Если же эти операции над строками часто и активно используются, нужно перевести строки в кодировку с постоянным числом байт на символ.
Но популярных алгоритмов, где нужны эти операции, я не припомню. Наоборот все стараются при работе со строками, избежать получения символа по позиции, а количество символов в строке имеет исколючительно статистическую и аналитическую ценность.

PS: Предлагаю зайти на unicode.org и почитать много интересного :)


Last edited by 046 on Thu Mar 16, 2006 9:02 am; edited 1 time in total
Back to top
View user's profile Send private message
046
Apprentice
Apprentice


Joined: 21 Jul 2004
Posts: 231
Location: Yaroslavl, Russia

PostPosted: Thu Mar 16, 2006 8:59 am    Post subject: Reply with quote

Koshh wrote:
Никто никогда не называл эексплорере старой и глючной программой, у эксплорера нет никаких проблем с отображением юникодных символов.
Ах Вы про интернет эксплорер? У него с отображением может и нет, а вот с передачей точно есть, как он корёжит данные форм, и как их восстанавливать, об этом целые поэмы написаны на сайтах www программистов.

Я-то имел ввиду китайский компактик (см выше).

Koshh wrote:
То есть KOI8 и UTF-8 вещи взаимосключаемые в линухе (пляски с конвертацией справки из одного формата в другой - это не решение, фактически это перекомпиляция программы). А винда 3 кодироваки одновременно есть (см. предидущие посты).

1. Лучше бы в виндовс не было 3 кодировок. Это косяк и костыль, правда обклееный войлоком, и описаный во всех путеводителях :) Но на него всё равно напарываются, правда проблем сильных обычно не возникает, результат обычно потеря 2-120 секунд и лёгкое раздражение :)

2. Автор mc выпендрился объеденив man страницу и встроенную помощь, в результате, помощь не была обработана стандартным инструментом для локализации программ. Все строки, обработанные нормальной локализацией, работают в разных локалях без пересборки и т.п.
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Thu Mar 16, 2006 5:32 pm    Post subject: Reply with quote

046 wrote:

Я-то имел ввиду китайский компактик (см выше).

1. Лучше бы в виндовс не было 3 кодировок. Это косяк и костыль, правда обклееный войлоком, и описаный во всех путеводителях :) Но на него всё равно напарываются, правда проблем сильных обычно не возникает, результат обычно потеря 2-120 секунд и лёгкое раздражение :)

2. Автор mc выпендрился объеденив man страницу и встроенную помощь, в результате, помощь не была обработана стандартным инструментом для локализации программ. Все строки, обработанные нормальной локализацией, работают в разных локалях без пересборки и т.п.


Про китайский компактик вроде как уже разобрались - винда китайский показывает, максимум что нужно сделать в не-китайской версии винды - сменить 1 шрифт, заданный по-дефолту. Хватит уже про него.

1. Кодировки в винде нужны для совместимости со старым софтом - который не слышал про юникод, и новых версий которого просто не предвидится. Решения для линуха - "ну... вот сырцы, переделайте сами" или же "ждите, пока кто-нить не портирует". Решение винды - оставить ненавистные тебе две кодировки (вернее, поддержку определенных кодовых страниц, но это не принципиально), дабы у юзеров было меньше проблем. И 120 секунд и раздражение - цветочки по сравнению с пересборкой системы, играми с конфигами и прочим - в случае обнаружения пингвиньих граблей.

2. Авторы xmms, mplayer - тоже "выпендрелись"? - иначе отчего при русской локали ничерта не видно (без неслабой обработки набором напильников)? Кстати, Xorg - часть ос, нравится это тебе, или нет. Алтернатив столько же, сколько и у эксплорера в винде.

ЗЫ Я говорю про оболочку (shell) виндовса. Файлик explorer.exe (как и в случае с ie) - всего лишь фронт-энд, не более.
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Thu Mar 16, 2006 6:07 pm    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

046 wrote:

Поскольку Вы считаете что я не понимаю, то начну учить :)
1.
В utf-8 символ может кодироваться последовательностью от одного до 6!! октета. (1 октет = 8 бит, практически тоже самое что и байт)
Все символы unicode НЕ ВЛЕЗАЮТ в 16 бит. И utf-8 была создана не для экономии (экономная она только на ASCII тексте), а для совместимости. Куча библиотек (в том числе и ядро linux) работает со строками как с последовательностями, заканчивающимися нулевым байтом. Для этого кодировка utf-8 подходит.

2. Любые данные можно представить как массив байт или машинных слов в памяти. Кстати машины с размером слова в 16 бит уже жуткая редкость :) Переход с 32 на 64 идёт. Да, в utf-8 нельзя в произвольном месте, заменить/вставить/удалить произвольный байт / слово / ещё какою нибудь фигню, не опасаясь, что изменения затронут весь последующий текст. Ознако заменять utf подстроку на utf, а также удалять и добавлять utf подстроки в любом месте можно совершенно свободно.
И это касается всех кодировок с переменным числом байт включая utf-16!
Unicode кодировки с постоянным числом бит (лишённые подобных недостатков) называются ucs (в противовес utf). Например ucs-4, в которой каждый символ кодируется 32 битами.

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


В кодировках с переменным числом байт на символ (включая utf-16), есть недостаток две медленно работающие операции.
1. Количество символов в строке. (в отличии от получения занимаемой строкой памяти, это крайне редкая операция)
2. Получения символа по его позиции. (также редкая операция в отличии от последовательного чтения символов)
Если же эти операции над строками часто и активно используются, нужно перевести строки в кодировку с постоянным числом байт на символ.
Но популярных алгоритмов, где нужны эти операции, я не припомню. Наоборот все стараются при работе со строками, избежать получения символа по позиции, а количество символов в строке имеет исколючительно статистическую и аналитическую ценность.

PS: Предлагаю зайти на unicode.org и почитать много интересного :)


Хорошо, что ты решил подучить матчасть =) Однако, мы тут вроде как не меремся объемами copy-paste с unicode.org и иже с ним. Теперь по пунктам:

1. Поскольку HTML и XML (сюда же SOAP) в качестве служебных символов используют исключительно символы ascii, то экономия получается нешуточная - именно при передаче запросов и документов. Узкое место - канал связи, а не объем жесткого диска. Про библиотеки еще смешнее "с последовательностью, оканчивающуюся нулевым байтом". Никто с этим и не спорит. Просто обработка единиц последовательности переменной длины требует дополнительных накладных расходов - в _любом_ случае. И попробуй доказать обратное.

2. Батенька, мы с вами про x86 говорим, где слово (word) имеет размерность 16 бит. И как ни странно, в AMD64 word тоже 16-ти битный. Точно так же как и байты - восьмибитные. Теперь про подстроки - повторяю для самых недогадливых - для получения длины подстроки недостаточно умножения количества символов на их размер (одна операция), а требуется циклических проход по всем символам, и суммирование размера каждого из них. Теперь начинаешь понимать? Однократное умножение ВСЕГДА быстрее цикла с аккамулятором - причем ГОРАЗДО. Что же касается точного и начного названия типов кодировок (а еще можно про порядок байт вспоминить) - это дело десятое. В винде вимвол == 2 байтам.

3. Ну ты еще про переполнение буфера вспомни, ей богу. Выше я показал, в чем проблема с определением длины строки - в скорости. Про отладку я говорю потому, что "на глазок" определить проблемы при обработке UTF8 строк крайне проблематично, и некорректно выдернутая подстрока может "мутировать" (в случае разрыва последовательности байт, кодирующих символ) во что угодно. В сложных алгоритмах (особенно при активном выделении/особождении памяти) отладка превращается в пытку - особенно, для начинающих программеров.

И два "маленьких пункта":

1. Каким образом ты определишь объем памяти, занимаемый стркутрой с членами переменной длины? Правильно, просуммируешь их размер (см выше). Как определить количество символов в UTF8 - строке? Правильно, оргпнизовать цикл. Итак, у тебя есть два варианта - или каждый раз использовать одну из этих двух _медленных- операций, или сопровождать строку дополнительным параметром, содержащим информацию о ее длине/размере. Первое грозит откровенными тормозами, второе - усложенением кода, и как вариант - потерей одного регистра общего назначения под параметер.

2. Получения символа по позиции - и впрямь редкая операция. Гораздо более частая операция - это получение подстроки. Но... Нам снова требуется ее (подстроки) размер в _байтах_ (нам ведь надо выделить под нее память). Способ получение - медленный цикл (по сравнению с одним умножением).

Сделаю небольшую ремарку - процессоры x86 имееют встроенные средства для облечения работы со строками - это инструкции LODS/SCAS/STOS (для 8, 16 и 32 битных символов). Также попогает режим адресации по базе с индексацией. Естественно, все это непременимо к UTF8.

Теперь займемся "популярными" алгоритмами. Один из самых "популярных" алгоритмов - это выделение подстроки (для UTF8 - медленный). Также довольно популярна операция соеденения строк - "аsвgвавd" + "XыXыX". Вопрос - сколько памяти надо выделить под результат? Ответ - хрен его знает, цикл покажет.
Back to top
View user's profile Send private message
046
Apprentice
Apprentice


Joined: 21 Jul 2004
Posts: 231
Location: Yaroslavl, Russia

PostPosted: Fri Mar 17, 2006 7:13 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

Koshh wrote:
Просто обработка единиц последовательности переменной длины требует дополнительных накладных расходов - в _любом_ случае. И попробуй доказать обратное.
Так я это успешно делаю. В большинстве случаев работа с UTF имеет аналогичную трудоёмкость.
А для всяких извратов - кодировки с постоянным числом байт на символ.
Koshh wrote:
Батенька, мы с вами про x86 говорим, где слово (word) имеет размерность 16 бит.
word имеет размер регистра общего назначения. И так везде, а не только в x86. Сексуальные проблемы синтаксиcа ассемблера intel тут не решают. :P
Koshh wrote:
повторяю для самых недогадливых - для получения длины подстроки недостаточно умножения количества символов на их размер (одна операция), а требуется циклических проход по всем символам, и суммирование размера каждого из них. Теперь начинаешь понимать?
Подстрока у тебя как задаётся? А то я не понимаю в чём проблема? Мне вот (как я писал выше) абсолютно не интересно сколько в строке (подстроке) символов. Мне интересно сколько она занимает места в памяти целиком. А для получения занимаемой памяти НЕ НУЖНО выяснять количество символов и складывать их размеры. (Я про это ещё повторю)
Koshh wrote:
В винде вимвол == 2 байтам.
Китайцы, корейцы, вместе с инженерами, физиками и математиками шутку оценили :)
Koshh wrote:
Выше я показал, в чем проблема с определением длины строки - в скорости. Про отладку я говорю потому, что "на глазок" определить проблемы при обработке UTF8 строк крайне проблематично, и некорректно выдернутая подстрока может "мутировать" (в случае разрыва последовательности байт, кодирующих символ) во что угодно.
Ты ничего не показал. А проблема о порчи при некорректном разрыве, касается любой unicode кодировки. Там есть "символы модификаторы", например добавляющий апостроф перед следующим ЛЮБЫМ символом ;)
Koshh wrote:
В сложных алгоритмах (особенно при активном выделении/особождении памяти) отладка превращается в пытку - особенно, для начинающих программеров.
Не имеет оношения к utf. Работа со строками c ручным управлением памятью не проста сама по себе.
Koshh wrote:
Каким образом ты определишь объем памяти, занимаемый стркутрой с членами переменной длины? Правильно, просуммируешь их размер (см выше). Как определить количество символов в UTF8 - строке? Правильно, оргпнизовать цикл. Итак, у тебя есть два варианта - или каждый раз использовать одну из этих двух _медленных- операций, или сопровождать строку дополнительным параметром, содержащим информацию о ее длине/размере. Первое грозит откровенными тормозами, второе - усложенением кода, и как вариант - потерей одного регистра общего назначения под параметер.
Ты не хочешь понимать что количество символов нужно в РЕДКИХ случаях. А для получения размера utf-8 строки, ограниченной нулём, можно воспользоваться функцией strlen стандартной библиотеки C.
Кстати в языках отличных от C где строка встроенный тип данных, часто хранится размер занимаемой памяти. И работет это не медленнее, а если строки большие - то и быстрее.
Koshh wrote:
Получения символа по позиции - и впрямь редкая операция. Гораздо более частая операция - это получение подстроки. Но... Нам снова требуется ее (подстроки) размер в _байтах_ (нам ведь надо выделить под нее память). Способ получение - медленный цикл (по сравнению с одним умножением).
Расскажи что такое подстрока. как ты её из строки получаешь? А места она будет занимать СТОЛЬКО ЖЕ как и занимала в строке! :) Адрес конца минус адрес начала :)
Koshh wrote:
Сделаю небольшую ремарку - процессоры x86 имееют встроенные средства для облечения работы со строками - это инструкции LODS/SCAS/STOS (для 8, 16 и 32 битных символов). Также попогает режим адресации по базе с индексацией. Естественно, все это непременимо к UTF8.
Жуткий бред. Функция strlen использует scas для определения размера строки и отлично работает с utf-8. Также без проблем работают функции по поиску позиции (адреса в памяти) подстроки. Режим адресации опять не пришей кобыле хвост. Тут не бокланы чтобы пугаться бреда из умных слов.

Резюме -
Для получения занимаемой памяти с utf-8 строкой можно обращатся как с ascii!!
Koshh wrote:
Теперь займемся "популярными" алгоритмами. Один из самых "популярных" алгоритмов - это выделение подстроки (для UTF8 - медленный). Также довольно популярна операция соеденения строк - "аsвgвавd" + "XыXыX". Вопрос - сколько памяти надо выделить под результат? Ответ - хрен его знает, цикл покажет.

1. Вы не правы (см выше)
2. Всё просто делай как с ASCII строками :) Это НАМНОГО проще чем пляски с двухбайтными символами :)

PS: Надеюсь что был вам полезен.
Back to top
View user's profile Send private message
kbps
n00b
n00b


Joined: 06 Mar 2006
Posts: 38
Location: Vladivostok, Russia

PostPosted: Fri Mar 17, 2006 8:08 am    Post subject: Reply with quote

:arrow:

Сколько дезинформации, прям таки FAQ по шрифтам надо делать!!!

:arrow:
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Fri Mar 17, 2006 8:20 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

046 wrote:
Так я это успешно делаю. В большинстве случаев работа с UTF имеет аналогичную трудоёмкость.
А для всяких извратов - кодировки с постоянным числом байт на символ.

Еще раз - одно умножение или цикл с суммированием (не забывай про проверку условия при каждой итерации) - что быстрее? Хваит уже голословных утверждений. Я считаю, что быстрее умножение. Твои аргументы в пользу цикла?

[quote="046"]word имеет размер регистра общего назначения. И так везде, а не только в x86. Сексуальные проблемы синтаксиcа ассемблера intel тут не решают.
Quote:

Мы говорим про конкретную архитектуру и вполне конкретный ассемблер, а также язык C. Хочешь опускать С - сходи на форум к разработчикам ядра сам-знаешь-чего =)

[quote="046"]А для получения занимаемой памяти НЕ НУЖНО выяснять количество символов и складывать их размеры.

Приведи пожалуйста сей магический способ! Например, для строки "АААAAAФФФAAA": сколько байт занимает подстрока "AAФ"?

046 wrote:
Ты ничего не показал. А проблема о порчи при некорректном разрыве, касается любой unicode кодировки. Там есть "символы модификаторы", например добавляющий апостроф перед следующим ЛЮБЫМ символом

См. пункт про быстродействие умножения и цикла. Как только ты сможешь ответить что-нить вразумительное, тогда и поговорим. Что же касается разрывов, то они возникнут исключительно у китайцев и с не самыми распространенными символами. В случае UTF8 же, проблемы случаются с русским и прочими европейскими языками. Вывод - у китайцев проблемы будут в любом случае, как там чего не кодируй (если не изобретать спец. китайских кодировок), а у европейцев- только с UTF8

046 wrote:
Не имеет оношения к utf. Работа со строками c ручным управлением памятью не проста сама по себе

Однако язык С (и в меньшей степени - CPP) подразумевают именно такую модель работы с памятью. Указатели, массивы, malloc и так далее. Надеюсь, ты не предлагаешь всем начинающим писать исключительно на VB? =) Тогда линукс зачахнет.

046 wrote:
Ты не хочешь понимать что количество символов нужно в РЕДКИХ случаях. А для получения размера utf-8 строки, ограниченной нулём, можно воспользоваться функцией strlen стандартной библиотеки C.
Кстати в языках отличных от C где строка встроенный тип данных, часто хранится размер занимаемой памяти. И работет это не медленнее, а если строки большие - то и быстрее.

Ну наконец-то дошло. Я тебе пытаюсь растолковать, что библиотечная функция для определения длины строки в UTF8 как раз и содержит тот самый пресловутый цикл. Который сильно медленнее умножения. А т.н. Pascal-строки, где первый байт содержит размер строки, крайне неудобен для применения в C. В С++ же используюся классы, как гораздо более удобный инструмент. Но классы - вещь неоднозначная, как и C++ (поинтересуйся опять таки у девелоперов).

И напоследок - бАкланы пишется через А. Жду в следующем сообщении пояснения, каким образом цикл работает быстрее одной операции умножения.
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Fri Mar 17, 2006 8:24 am    Post subject: Reply with quote

kbps wrote:
Сколько дезинформации, прям таки FAQ по шрифтам надо делать!!!

Да ладно тебе, дай повыступать =) Форум - это не средство для поиска истины, а способ отточить свои аргументы в споре. Да и просто забавно про бОкланов почитать =) Короче, мы с этим чудом не серьезно говорим, а развлекаемся.
Back to top
View user's profile Send private message
Azik
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 151
Location: Russia, Ufa

PostPosted: Fri Mar 17, 2006 8:55 am    Post subject: Reply with quote

Граждане, а вы нить разговора не потеряли? Может вам того, в другой форум перехать? Для программистов С++ например.

Инересный исторический анекдот откопал: http://groups.google.com/group/relcom.comp.os.cmp/msg/73bd87373d9d09e1?hl=ru&. Вона какие казусы.
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Fri Mar 17, 2006 9:24 am    Post subject: Reply with quote

Azik wrote:
Граждане, а вы нить разговора не потеряли? Может вам того, в другой форум перехать? Для программистов С++ например.

Инересный исторический анекдот откопал: http://groups.google.com/group/relcom.comp.os.cmp/msg/73bd87373d9d09e1?hl=ru&. Вона какие казусы.

Очень даже может быть и потеряли =) Разве это кому-нить мешает? - стоят двое и о какой-то фигне разговаривают =)))

А анекдот и в самом деле интересен. Хотя... Все ведь помнят, как Билл ДОС прикупил, а потом перепродал ее IMB? =)
Back to top
View user's profile Send private message
046
Apprentice
Apprentice


Joined: 21 Jul 2004
Posts: 231
Location: Yaroslavl, Russia

PostPosted: Fri Mar 17, 2006 9:25 am    Post subject: Re: Нужен нормальный текстовый ре Reply with quote

Koshh wrote:
Например, для строки "АААAAAФФФAAA": сколько байт занимает подстрока "AAФ"?
strlen("AAФ")
046 wrote:
Что же касается разрывов, то они возникнут исключительно у китайцев и с не самыми распространенными символами. В случае UTF8 же, проблемы случаются с русским и прочими европейскими языками. Вывод - у китайцев проблемы будут в любом случае, как там чего не кодируй (если не изобретать спец. китайских кодировок), а у европейцев- только с UTF8
Ты сначала узнай как в уникоде кодируются всякие умляуты европейские. А потом пиши фигню :) И ни у кого проблем нет если учитывать что кодировка многобайтная. Сдвиг в любом уникоде страшен. А utf-8 портится только до ascii символа :)
Koshh wrote:
Я тебе пытаюсь растолковать, что библиотечная функция для определения длины строки в UTF8 как раз и содержит тот самый пресловутый цикл. Который сильно медленнее умножения. А т.н. Pascal-строки, где первый байт содержит размер строки, крайне неудобен для применения в C. В С++ же используюся классы, как гораздо более удобный инструмент. Но классы - вещь неоднозначная, как и C++ (поинтересуйся опять таки у девелоперов).
Цикл поиска нулевого символа? А тебе известен иной способ узнать размер С строки?
Кстати цикл из одной инструкции будет работать быстро :) jnz scasb или как-то так :)
Ты всё пишешь о каком-то умножении. Что за умножение?
То есть, например, ты занешь что в строке 7 символов, и легко можешь посчитать что она займёт 7*x байт? Я же пишу что это совсем не нужно. Более того ЭТО НИЧЕМ не отличается от того что ты УЖЕ знаешь что строке для размещения в памяти нужно y байт.
А сколько в ней символов НЕ ИМЕЕТ значения.
Koshh wrote:
И напоследок - бАкланы пишется через А. Жду в следующем сообщении пояснения, каким образом цикл работает быстрее одной операции умножения.
Не путай боклановъ с бакланами.
Какой цикл и какого умножения?
И с какой целью? У меня подозрения в целесообразности данных операций.
Back to top
View user's profile Send private message
Koshh
n00b
n00b


Joined: 03 Mar 2006
Posts: 32

PostPosted: Fri Mar 17, 2006 11:45 am    Post subject: Reply with quote

046 wrote:
strlen("AAФ")

Браво! Только в данном случае мы знаем еще и длину подстроки в символах (без этого знания само понятие подстроки не имеет смысла). Таким образом, можно либо послать strlen искать конец строки, либо умножить количество символов в подстроке на размер символа и получить ответ =) Разницу ощущаешь?

046 wrote:
Ты сначала узнай как в уникоде кодируются всякие умляуты европейские

А иероглифы ктайские? =) Мы говорим о конкрентных вещах - о том, что кодировки с переменно длиной символа в принципе очень "неповоротливые", и добавляют сложности программному коду.

046 wrote:

Цикл поиска нулевого символа? А тебе известен иной способ узнать размер С строки?
Кстати цикл из одной инструкции будет работать быстро jnz scasb или как-то так

Снова повторяю - при операциях с подстрокой программисту известны позиции первого и последнего символа, т.е. длина строки в символах. Как это можно использовать - см. выше. Что же касается скорости цикла - то как минимум пара цсловных переходов + inc eax скушают ресурсов больше, чем одинокое умножение. Устал уже об этом говорить.

046 wrote:

То есть, например, ты занешь что в строке 7 символов, и легко можешь посчитать что она займёт 7*x байт? Я же пишу что это совсем не нужно. Более того ЭТО НИЧЕМ не отличается от того что ты УЖЕ знаешь что строке для размещения в памяти нужно y байт.

См. тему про подстроки выше. В случае "просто строки" искать конец все равно прийдется, а при вставке/копирвоании/выделении памяти гораздо удобнее (и быстрее) использовать значения индексов символов.

046 wrote:
Не путай боклановъ с бакланами.

После пары твоих ответов я в самом деле замечаю разницу между гордыми птицами и бОкланами =)))
Back to top
View user's profile Send private message
046
Apprentice
Apprentice


Joined: 21 Jul 2004
Posts: 231
Location: Yaroslavl, Russia

PostPosted: Fri Mar 17, 2006 12:15 pm    Post subject: Reply with quote

Не нужно знание количества символов ни в строке ни в подстроке, при использовании unicode. По простой причине, это не говорит о том сколько места потребуется для вывода на экран или на принтер.
Подстрока это часть строки. Не больше. Почему без количества символов подстрока теряет смысл? Из какого места ты знаешь длинну подстроки в символах? Я из него же достану длинну строки в байтах.

Вот именно что при операциях с подстрокой известны ПОЗИЦИИ. То есть адреса. В байтах!!! А не в символах. А символы засунь туда, откуда взял длинну подстроки )

Я обычно не хочу этого знать, я пользуюсь utf-8, ты хочешь - пользуйся другим. Если мне надо будет - легко перекодирую в нужную мне кодировку для обработки.

Ты много говоришь о сложностях и неповоротливости, а конкретных примеров так до сих пор и нет. Зато бреда выше ты написал что я зачитался. Одно радует, что такие болтуны вроде тебя, в серьёзных работах, где нужны квалифицированные замечены не бывают.

Я не понял кто тебе в Utf-8 мешает использовать индексы?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Russian All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum