История появления null-терминированных строк

Сишка – это именно продукт убогости PDP-11.

Система команд PDP-11 очень красива. С некоторой сноровкой там даже Ассмемблер не нужен, можно сразу писать в машинных кодах.

влиянием системы команд PDP-11

Будто что-то плохое.

Относительные смещения для условных переходов высчитывать муторно. Но да, реально.

Но вообще, разве для строк сейчас char* кто-то использует?

char* для UTF-8 подходит

Точнее говоря, копирование выглядит как while (*dst++ = *src++);

Предполагалось что будут писать не на алголе, а на языке который будет создан на основе него. Все компиляторы насколько я понял, были очень разными.

Если в Си программа, то используют.

Почти все проекты на С которые работают со строками? А «под копотом» нуль терминированые строки используют все программы которые работают с файлами, syscall open требует на вход именно такую строку.

влиянием системы команд PDP-11

Будто что-то плохое.

Да. Твой компьютер сегодня – не PDP-11.

Си используется для разного железа, поэтому то что amd64 и pdp-11 разные, это не так важно. Нужна же какая то абстракция для переносимости, и pdp-11 не худший вариант.

Видимо потому что Алгол это продукт исследовательской деятельности, изначально направленной на написание стандарта, а Си самозародился как средство достижения практической цели - написать на нём UNIX. А так Си появился конечно позже но разница не настолько большая.

Си используется для разного железа, поэтому то что amd64 и pdp-11 разные, это не так важно. Нужна же какая то абстракция для переносимости, и pdp-11 не худший вариант.

Да нет, это важно. Мы из-за этого имеем всякие Meltdown и прочие Spectre, потому что твой amd64 пытается притворяться pdp-11 и делает это иногда довольно херово.

Это проблема процессоров а не языка программирования.

while (*dst++ = *src++);

Какой же всратый код. Будь размер известен, то можно было бы копировать бОльшими кусками, а не по байтику.

Например?

Например?

На 32/64 битный процессорах можно сразу по 32/64 бита (4/8 байт) копировать.

С AVX можно уже по 256 бит (32 байта) копировать. С AVX-512 по 512 бит (64 байта).

Да, но у нас 1973 год и 16-битный PDP-11

Да, но у нас 1973 год и 16-битный PDP-11

Как по мне имелось ввиду что просто перекомпилировав с обновленной стандартной библиотекой можно было бы сразу получить большую производительность. А так надо код переписывать.

А, точно. Я вообще utf-8 считал кодировкой, а так-то про wchar думал

Я про glib, который буквально все используют.

Имхо, нультерминированные строки, это наверное худшее, что пришло к нам от С. И куча костылей для работы со строками оттуда же.

Наоборот, нультерминированные строки должны быть хаком(указатель на массив), там где нужна особая скорость. А вот для стандартных строк, намного лучше было бы что-то вроде паскалевских. Но имеем, что имеем. И страдаем.

Так UTF-8 и есть кодировка на основе 8-битных символов, а потому обратно совместима с ASCII. Wchar — это винда в основном.

Это проблема процессоров а не языка программирования.

Это проблема процессоров, вызванная повсеместным использованием одного однобуквенного языка программирования.

Видимо потому что Алгол это продукт исследовательской деятельности, изначально направленной на написание стандарта, а Си самозародился как средство достижения практической цели - написать на нём UNIX. А так Си появился конечно позже но разница не настолько большая.

Почему сишники постоянно пишет об «исследовательской деятельности» как о чём-то плохом?

Да нет, seq_buf в ядре вполне норм работает. Собственно, строки там потихоньку в seq_buf и превращают.

Костыль от безысходности.

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

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

С чего ты взял что С накладывает такое ограничение?

Потому что сишка требует последовательную модель выполнения. См. стандарт языка.

Это про абстракцию выполнения, машина может исполнять это как угодно, главное соответствовать стандарту.

Так же ключевое слово register не обязывает машину иметь регистры в которые можно ложить переменные, она может быть стековой.

Это про абстракцию выполнения, машина может исполнять это как угодно, главное соответствовать стандарту.

Ага. Отсюда растут ноги у спекулятивного выполнения, результаты которого отбрасываются. Но не всегда, и это вырождается в вышеупомянутые Spectre и Meltdown.

Как по мне имелось ввиду что просто перекомпилировав с обновленной стандартной библиотекой можно было бы сразу получить большую производительность. А так надо код переписывать.

Так если не нуль-терминированные строки использовать, а строки с заранее известной длиной, то копирование такой строки сводится условно к библиотечной memcpy, которая уже хорошо оптимизирована.

Кстати без интринсиков у меня получилось заставить GCC vmovdqu64 использовать, которая по 64 байта копирует: https://godbolt.org/z/GxxobEMYY

Интелу не обязательно так делать, что бы программы на С выполнялись, они могли бы сделать архитектуру которую ты хочешь, и все нормально бы скомпилировалось, но думаю покупатели потерю бинарной совместимости не поймут.

Интелу не обязательно так делать, что бы программы на С выполнялись

Нет, но интелу обязательно так делать, чтобы программы на C выполнялись быстрее чем у конкурентов.

они могли бы сделать архитектуру которую ты хочешь, и все нормально бы скомпилировалось, но думаю покупатели потерю бинарной совместимости не поймут.

Они пытались убить x86 трижды и все три раза выходило говно: сначала iAPX432, потом i860/i960, а потом Itanium. Из них взлетел только i860/i960 и в основном в ебмеддеде, потому что это был просто неплохой RISC-чип.

Нет, но интелу обязательно так делать, чтобы программы на C выполнялись быстрее чем у конкурентов.

Я считаю что нет, у тебя есть конкретные примеры?

Нет, но интелу обязательно так делать, чтобы программы на C выполнялись быстрее чем у конкурентов.

Я считаю что нет, у тебя есть конкретные примеры?

Примеры чего? Что процессор со спекулятивным выполнением быстрее чем без него? Ну, добавь в командную строку ядра mitigations=off и сравни. Будет 100% быстрее, особенно если у тебя проц ~5-6-летней давности.

И если размер неизвестен то тоже можно копировать большими кусками, как это делает strcpy.

Вот и используй пхп там где тебе скорость не нужна. В нём как раз так как ты хочешь. Лезут и лезут в Си со своими «гениальными» идеями как его улучшить.

Это проблема процессоров, вызванная повсеместным использованием одного однобуквенного языка программирования.

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

Почему сишники постоянно пишет об «исследовательской деятельности» как о чём-то плохом?

Ты что-то выдумал.

Это не костыль, а штатная штука.

Последовательное выполнение требуют программисты. И уже под их нужды делаются языки. Непоследовательные языки тоже есть, но как-то особой популярностью не пользуются.

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

Процессоры сильно подешевели со временем, если учитывать инфляцию. Никто тебе ничего не впаривал.

Последовательное выполнение требуют программисты.

Нет, этого требует стандарт языка C. Ты бы знал об этом, если бы ты его читал, а не ныл в каждом сишном треде что комитетчики тебе язык испортили и делают неправильные компиляторы.

Непоследовательные языки тоже есть, но как-то особой популярностью не пользуются.

Непоследовательный – это ты.

Ты сам выше мою фразу подтвердил:

Нет, но интелу обязательно так делать, чтобы программы на C выполнялись быстрее чем у конкурентов.

Причина - недобросовестная конкуренция. Ради видимой покупателю характеристики забили на всё остальное.

Нет, этого требует стандарт языка C. Ты бы знал об этом, если бы ты его читал, а не ныл в каждом сишном треде что комитетчики тебе язык испортили и делают неправильные компиляторы.

Стандарт C такой, потому что такой язык нужен программистам, а не потому что какой-то тайный вредитель решил всем навязать последовательное исполнение.

Причина - недобросовестная конкуренция.

Что в ней недобросовестного?

Ради видимой покупателю характеристики забили на всё остальное.

Покупателя интересует как быстро будут выполняться программы. Если они выполняются быстрее, значит процессор лучше. Остальное его не интересует.

Вот так и возник симбиоз делателей процессоров и программистов на сишечке: Intel делают не просто более быстрые процы, они делают их более быстрыми в выполнении сишного кода.

Стандарт C такой, потому что такой язык нужен программистам, а не потому что какой-то тайный вредитель решил всем навязать последовательное исполнение.

Нет, стандарт такой потому что его писали наркоманы, которые пытались сохранить совместимость с кодом, написанным под PDP-11.

Людям удобнее писать программы у которых нормально прослеживается порядок исполнения. Ещё раз повторю, языки где такого нет вполне существуют (функциональные), но популярностью они не пользуются - большинству на них неудобно программировать.

Людям удобнее писать программы у которых нормально прослеживается порядок исполнения.

Ну, да? Это вообще любой язык программирования, включая…

Ещё раз повторю, языки где такого нет вполне существуют (функциональные), но популярностью они не пользуются - большинству на них неудобно программировать.

В функциональных языках всегда есть чёткий порядок выполнения кода лол.

Но ты не с тем споришь. Сишечка требует, чтобы одна команда завершилась полностью до того, как начнётся другая. Что входит к конфликт с такими штуками, как – ну я не знаю – конвейер в процессоре.

В результате получаются лулзы, когда нужно руками расставлять memory barriers в коде, чтобы компилятор не насовал параллельности, процессор не переиначил инструкции как ему удобнее и сишнику не оторвало жопу.

А потом сишники всё равно ходят и рассказывают про неправильные компиляторы и злобные процессоры, портящие их идеальный код.

Сишечка требует, чтобы одна команда завершилась полностью до того, как начнётся другая. Что входит к конфликт с такими штуками, как – ну я не знаю – конвейер в процессоре.

Это не «Си требует», это подсознательное ожидание большинства программистов от последовательно написанного кода. В стандарте Си данное ожидание видимо просто задокументировали (как и большинство того, что в нём написано - писалось не как директива, а как описание текущей ситуации).

Расширяемость. Выделили бы 1 байт на длину строки как в Pascal, были бы строки 255 символов. Выделили бы 2 байта, то с одной стороны кто-нибудь бы ныл, что целый байт впустую расходуется, потому что ему не нужны длинные строки, но при этом строки бы устарели с развитием компьютеров, потому что 64К символов тоже бывает мало. А 4 байта никто бы в те времена не выделил, потому что никто не знал, что будут массовые компьютеры с такими огромными объёмами памяти.

А null-terminated строки получились такие, что стандарт из прошлого века и сишные алгоритмы работы с этими строками практически без изменений могут работать даже на современных 64-битных машинах и обрабатывать строки размеров с ОЗУ.

Это не «Си требует», это подсознательное ожидание большинства программистов от последовательно написанного кода.

Да, это кстати тоже проблема. Большинство программистов вообще часто не очень понимают, что они делают. Особенно сишники. Но это в порядке вещей.

В стандарте Си данное ожидание видимо просто задокументировали (как и большинство того, что в нём написано - писалось не как директива, а как описание текущей ситуации).

Это не ожидание, это требование к реализации абстрактной машины для C.