Это все пфигня.

Насколько я понял твои слова, основным аргументом у тебя является то, что мы можем завернуть весь юникод в набор функций специализированного API для работы со строками, "с операциями 'следующий символ' и 'предыдущий символ'" и в дальнейшем манипулировать строками только в асбестовых перчатках посредством API. Причем получившееся API может быть достаточно логично, чтобы его на самом деле можно было бы использовать.

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

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

И наконец - а почему это, собственно, ты запрещаешь мне пользоваться произвольным доступом? Потому что юникод делает такую операцию непредсказуемо сложной? Ну так это проблемы юникода, а не мои, тебе не кажется?

(Reply to this) (Parent) (Thread)

Пойду с конца.

1. Юникод не делает произвольный доступ непредсказуемо сложным. Массив машинных целых в доступе ничуть не сложнее массива байт, а за пределы машинного целого юникод выйдет еще, гм, нескоро - само машинное целое растет быстрее. Непредсказуемо сложной и глючной делает работу с текстом сам подход произвольного доступа. Провоцируя кодера использовать неадекватные средства работы с текстом, начиная с изобретения велосипеда. Перл, скажем, позволяет произвольный доступ. Но делает его достаточно неудобным/непривычным в записи, чтобы спровоцировать использование более адекватных средств.

2. При вводе-выводе у тебя все равно используется API. Только надо использовать адекватный API - для ввода-вывода символов, а не байт, как сейчас. У перловых read и print почему-то нет никаких проблем с вводом-выводом символов. А у сишных, что printf/scanf, что write/read - почему-то есть. К чему бы это?.. Ну да, при асинхронном вводе-выводе ты можешь оказаться в ситуации, что транспортный уровень донес до тебя нецелый символ. Ну так и сейчас ты можешь оказаться в ситуации, когда транспортный уровень принес тебе нецелую логическую единицу. Ситуация разрешается точно так же, только разрешение ее можно упрятать в API, а не развлекаться этим каждый раз вручную. А то, что единица транспортного уровня в принципе не может гарантированно вместить целый символ - мала слишком - это реальность. данная нам в ощущениях, с этим бороться невозможно.

(Reply to this) (Parent)