Запретите мне

[metaclass]

Мне нельзя писать на C, по причине психологических проблем. Я начинаю от входа изобретать велосипеды, писать какие-то свои строки, массивы строк и прочую хрень.
Впрочем, в целях самообучения оно, конечно, полезно, но потом надо заставить себя взять готовые библиотеки и переписать на них.
Тогда возникает следующая проблема: какую из 100500 библиотек взять?
А вообще это я пытаюсь сделать общение с девайсом в continuation-passing style с трамплином, но начав его делать, я углубился в строки и списки строк )

PS: Наверно возьму glib. Код строк у них там внезапно почти идентичен тому, что я тут наколхозил.
PPS: Хотя уже есть и альтернативное мнение в комментариях. Ну и спрашивается, как жить в языке, где на каждую тему есть половина мнений за и половина мнений против?:)

Comments

[permea-kra.livejournal.com]

в сях нет, не было и не будет нормальных строк, поскольку все стандартные апи хотят нуль-терминированные строки. Там нужно все выкидывать на свалку и переписывать. Начать желательно с написания нового unicode (чтобы вся диакритика была всегда отдельным code point), потом переписать все апи на строки с информацией о длине в байтах перед строкой и использованием нормального utf8 и только после этого выпускать язык из психушки.

[tzirechnoy.livejournal.com]

Если человек считает utf8 нормальным -- то выпускать его из психушки пока рановато.

[permea-kra.livejournal.com]

Кодировка в любом случае должна быть 1)байт-ориентированная (чтобы не было идиотизма с LE/BE) 2)с нормальным расходом памяти, сниженным для частых символов 3)желательно, являться надмножеством ascii. 4)хотя бы миллионом кодпойнтов.

Итого, альтернатив UTF8 в общем нет.

[tzirechnoy.livejournal.com]

>Кодировка в любом случае должна быть

настраиваемой пользователем.

>1)байт-ориентированная (чтобы не
> было идиотизма с LE/BE)

Транспортная -- да. Со внутренней в принцыпе могут быть варианты, это в общем скорее дело библиотеки.

>с нормальным расходом памяти, сниженным для
> частых символов

preliminary optimisation. Если нужэн снижэнный расход памяти -- используйте хаффмана. А вообще написать столько настоящего текста, который займёт существенную память -- нетривиально.

>желательно, являться надмножеством ascii.

Вообще хорошо бы. Хотя лучшэ, чтобы поддержка не-ascii тожэ была.

>хотя бы миллионом кодпойнтов

Вы столько не выучите.
То есть транспортная и системная инфраструктура должна поддержывать расшыряемый набор кодировок, по очевидной причине. В расшыряемом наборе будет неограниченное количество кодпоинтов. С другой стороны, мне часто хватает windows-1251 с парой эскейпов.

Вообще, мне бы подошла rfc2047, если чо.

[permea-kra.livejournal.com]

>preliminary optimisation.
Это ярлык.

>Если нужэн снижэнный расход памяти -- используйте хаффмана.
Не всегда вариант. Зачастую совсем не вариант.

>А вообще написать столько настоящего текста, который займёт существенную память -- нетривиально.
Банально. Сериализованная база имя-телефон-адрес.

>Вы столько не выучите.
Мне и не надо. Юникод просто один должен быть.

[esil0x.livejournal.com]

> 2)с нормальным расходом памяти, сниженным для частых символов
Это зависит. По мне так лучше 4 байта на символ и высокая производительность.

[nealar.livejournal.com]

Производительность так часто утыкается в память, что это почти взаимоисключающие параграфы.

[esil0x.livejournal.com]

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

[jakobz.livejournal.com]

Это хотя-бы лучше UTF16.