qivi писал(а): как работать со строками в рамках концепции нового FPC
А нет там ничего нового в рамках того, как обычно реализуются такие схемы работы. As пример C#, C/C++, JAVA. В качестве внутренней кодировки, с которой работает как компилятор, так и сами библиотеки рантайма, выбирается максимальный юникод, доступный для базовой операционной системы [в fp это UnicodeString=UTF16, поскольку вы понимаете, что это windows-компилятор по своему происхождению и основной области применения], при запуске программы считываются установки системной локали [в fp для этого надо явным образом показать компилятору кодировку исходного текста программы aka {$codepage}], все операции ввода-вывода корректируются под кодировку этой локали, чтобы при чтении во внутреннее представление получились правильные неискаженные строки. Всякое извращение, типа байтовых строк и прочего, является нонсенсом и используется только в исключительных случаях для взаимодействия с какими-нибудь внешними или старыми библиотеками [а вот тут, благодаря зоопарку, происходящему от Delphi и существованию маркированных AnsiStrings, картина размазывается], работа библиотек I/O с чем либо, имеющим другую кодировку, отличающуюся от системной по умолчанию, либо вообще никак не поддерживается [fp, gcc/g++], либо поддерживается явным указанием кодовой страницы при открытии текстового файла [в fp не реализовано, есть в .NET и JAVA]. Т.е. в рамках fp слепое следование концепции на сегодняшний день - полный отказ от любых строк, кроме UnicodeString (как в C/C++ - использование только wstring, wchar, wchar*). Как то так. ))
Обратной стороной медали, при слепом следовании концепции, получите крайне медленно работающие программы.
Я, конечно, допускаю, что у меня руки кривые, но сколько не пытаюсь тестов на разных языках созидать, получаю в среднем следующую картину при работе со строками: Си на первом месте при работе на указателях и байтовых строках (т.е., код, подогнанный под рунтайм и особенности языка), на втором месте по производительности, как ни странно, жабка, причем при отсутствии каких либо попыток оптимизации, на третьем месте - C# в версии .NET, опять же без явной оптимизации; и FP (при равной производительности с C# NET, на байтовых строках при попытке минимизации присвоений на уровне языка (то есть, в ассемблер еще не лезли, но это уже отнюдь не соответствующий алгоритму код, а подгонка под скорость). Обрушить производительность?
Запросто! C# -> под Linux + Mono. Это сразу выводит его в аутсайдеры. FP меняем строки на UnicodeString -> имеем производительность еще ниже. Жабку сажаем на одноядерный процессор без гипертрединга, она махом уравнивается с fpc (ну или заставляем ее считать плавающую математику). Тоже как то так. ))
