eee-pc
а сколько кодировок появилось за это время, ппц. почему например все flash видео сайты делают свой формат, не совместимый с другими ? тоже и здесь. это не си заставляет делать си-строки (кстати сказать, что си-строки вполне достойны, кроме того, самые быстрые из всех). это удары под ребра заставляют крутится
1) Честно говоря я не понял связи с flash video. Возможно вы имели в виду что-то другое?

2) C-строки не могут быть быстрыми или медленными. Они не могут быть никакими потоу что их просто не существует. Есть некая каноническая библиотека (объявленная string.h) для работы с ASCIIZ-массивами. С этого начинается любое программирование строк на низком уровне.И все начинающие сишники её изучают. Это как ассемблер. Но она не лишена недостатков. Например, довольно сложно сделать return string из функции, особенно если она рекурсивная. Сложно конкатенировать строки в условиях расположения в стеке. И еще много чего сложно. Есть также немалый процент нареканий со стороны безопасности С-кода. Существуют эксплоиты, испольуют атаку на ASCIIZ массивы. Но..... существует масса прикладных библиотек. Каждая из которых навязывает свою собственную концепцию работы со строками. MFC, VCL, STL, и прочие *L создают свой собственный ни с чем не совместимый набор абстракций. Но ни одна из них так и не стала частью ЯЗЫКА. Они по прежнему остаются custom-библиотеками. И программист С++ должен лавировать между ними, выбирая удобную для себя методику. А когда методик несколько.... начинается АЛИС КАПУТ, о котором мы писали выше.

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

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

Мне кажется что это как раз явный алгоритмический антипаттерн. Поиск нуля, действительно тривиален, но если эта операция будет в цикле то вы получите серъёзную просадку в производительности. А если строка при этом буде расти в размере, то можно получить и квадратичную и кубическую сложности алгоритмов.

Хранить длину строки отдельно - тоже антипаттерн. Но уже не алгоритма а дизайна. Такой код трудно сопровождать.

2 All

По поводу ASCIIZ. Я немножко поковырял поисковики на предмет истории возникновения ASZII-нулевых строк. Первые сообщения об этом формате мелькают в статьях, посвящённых PDP (Programmed Data Processor). Это семейство довольно древних ЭВМ. Так вот. Из обрывков информации я узнал, что ASCIZ строка имела аппаратную реализацию на PDP. Впоследствии формат был перенесён на Intell архитектуры, у которых не было этой поддержки, из за чего, Pascal строки на Intell работают эффективнее.

Изопропил...
Что-то типа того. Две ассемблерные команды копируют строку из источника в получатель.
Насчёт версии - к сожалению не уточнил. Но мне гуглить уже лениво. Так-что если хотите - ищите сами.