Как лучше хранить строки в интерпретаторе языка?

кстати в том же питоне есть такие операторы над строками...

интересная статья на тему, почему создатели языка go выбрали кодировкой по умолчанию utf-8, а не utf-16:
http://benlynn.blogspot.com/2011/02/utf-8-good-utf-16-bad_07.html

 

Я подумал-подумал, и надумал вот что. Если глянуть повнимательнее, то большинство программ ведь не работает серьёзно со строками. Немного покопируют строки туда-сюда, распарсят int или float, наоборот преобразуют число в строку. И им по-любому не нужен рандом-акцесс к символам строки. Ну и пускай они работают с utf8. А те программы, которым это будет неудобно, легко могут написать свою собственную библиотеку для работы с UTF32. Более того, если мы глянем на тот же C, точнее на парсеры написанные на C, то заметная их часть реализует свои собственные строки, причём делают они это по-разному. И это не удивительно: разные парсеры хотят разных возможностей от строк, но чем больше возможностей будет заложено в структуру данных строки, тем глубже в библиотечном коде будут зарыты проблемы производительности. Например, с той же конкатенацией. Конкатенация -- это по-любому выделение памяти. Но если библиотека не поддерживает конкатенации, то клиентский код будет работать со строками так, чтобы обойтись без конкатенации и без выделения памяти. Скажем, код может завести единый массив char'ов, в котором он будет конкатенировать строки. При необходимости увеличивая размер этого массива realloc'ом. Но не освобождая его за ненадобностью, а используя для следующей операции конкатенации. Таким образом количество realloc'ов будет зависеть не от количества конкатенаций, а от максимальной длины результата конкатенации, причём зависимость эта легко делается логарифмической.
Кстати это соображение, как я понимаю, и является основной причиной того, что в C нет адекватной поддержки строк. Есть лишь минимальная, в виде строковых литералов и простейшего формата хранения строки.
Это не значит, что надо следовать примеру C, и создавать язык без поддержки строк. Но стоит последовать примеру C и реализовать поддержку строк в том объёме, который будет необходим 90% программ написанных на этом языке. А оставшемуся десятку процентов программ дать возможность реализовать строки самостоятельно.
Таким образом напрашивается использование utf8, и поддержка utf16/utf32 на уровне библиотек. Кстати что-то в этом роде в D сделано, я с D знаком лишь в рамках статьи на wikipedia, но я чётко помню, что там упоминалось три символьных типа в D. И все три разного размера.

ps. Хотя подумал... Если речь идёт о написании интерпретатора байткода, то наверное уже поздняк метаться, предлагать решения проблем уровня дизайна языка. =)

 

Rel

Да там большей частью всё те же разговоры в пользу бедных: ANSI, null-terminated и прочее. В начале 90-х может и был смысл всем этим заморачиваться, но сейчас-то кому она нужна, эта мертвечина? Только про "640 килобайт достаточно всем" не упомянули - слишком уж жалко по нынешним временам выглядело бы это нищебродство, когда даже в телефонах по два гига ОЗУ и можно хоть UTF-128 использовать.

 

Короче, давно надо всем просто-напросто перейти на нуль-терминейтед 32-битные строки и вообще забыть про данные размером меньше 32 бит. Типа все, char и dword - синонимы

 

Dmitry_Milk

Строки с завершающим символом - г0вно. Вот представь, есть у тебя в памяти "Война и мiръ" одной строкой... Не, "Война и мiръ", сцука, короткая. Пускай лучше будет последнее издание Страуструпа. И вот захотелось тебе узнать длину Страуструпа в буквах. Так что теперь, весь зетабайт шерстить в поисках символа-терминатора? Уж лучше счётчик в начале поставить на 64 бита. Или на 128. Просто делаешь жик-жик, и вот она, длина, всего в две ассемблерные команды.

 

ну никто не мешает и то и то использовать, скажем, в классах, инкапсулирующих строки.

 

CyberManiac
А потом Вы захотели вывести весь текст учебника в окно edit, а на конце нет терминатора. Придётя выделять память на символ больше, копировать. Кажется, это немного более затратно, чем вычислить длину.

 

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

 

ascii?

Зачем Вам длина в символах? Храните везде в байтах - какая проблема? Строки обычно обрабатываются посимвольно и get_next_char на utf8 спокойно отработает.

 

sergegers

Ну так в Delphi и QT это самое и сделали - строка в 16-битной кодировке с (почти) фиксированным размером символа, счётчиком и завершающим символом для простоты общения с виндами да хрюниксами.

srm

日本語?

 

CyberManiac

это был стёб, если Вы не поняли.