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

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

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

программисты ожидают от кода такое поведени

Да-да-да. Я понял. Только их ожидания очень часто к реальности отношения не имеют.

Поэтому все претензии к данному пункту сразу переадресуй им. И касается это не только Си-программистов, а много каких.

Да не, меня всё устраивает. Я смотрю на подрывы сишных жоп и ем попкорн. Вот эта фигня, то что компиляторы делают с кодом при UB и прочее – это то, за что я так люблю C. Т.е. я сам научился худо-бедно с этим справляться, а вот то, как типичные сишники отстреливают себе ноги, никогда не надоест.

Примеры того как С ограничивает процессоры.

Вот эта фигня, то что компиляторы делают с кодом при UB

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

А вот сишные UB на этот счёт связаны с уже не спекулятивным, а вполне реальным выполнением, только проявляются они только в мультитреде и положения стандарта не нарушают (потому что в нём про мультитред такого требования нет). А вот ожидания программистов всё так же регулярно нарушают, да, потому что программисты часто ожидают последовательное выполнение и в мультитреде (точнее, в том как один тред видит действия другого) тоже. И именно поэтому получаются необъяснимые race condition в коде, не обвешанном синхронизационными примитивами (мютексы, атомики, итд) во всех опасных местах.

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

Стандарт C такой, потому что такой язык нужен программистам

Стандарт ANSI С в основном описывает состояние компиляторов.

а если осилил?

Видимо нет.

Где тут выдают диплом заслуженного сишника

Тут не выдают. Но если у вас есть хоть один, то можете похвастаться.

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

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

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

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

Во-первых в те времена никто не парился на счёт безопасности, корректности и т.п.

Еще как парились, даже архитектуры специально выдумывали, я выше писал, но как и сейчас, далеко не все этим хотели заниматься.

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

Есть еще вариант 7 - строка это связный список char. И 8 - строка это связный список элементов, каждый из которых является строкой или char

даже архитектуры специально выдумывали

Выдумывали, выдумывали, да недовыдумывали. Ты ещё ЛИСП-машины вспомни.

И 8 - строка это связный список

Похоже на горе rope.

Но стоит отметить что мультитред на Си в ответственных местах всё же относительная редкость (только ядра ОС и базы данных вспоминаются из частого).

А, да, сишники не осилили многопоточность. То, что на каком-нибудь Erlang пишется легко и без напряга, на си вызывает столько проблем, что сишники просто не могут.

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

Про Erlang слышал что это хороший язык, но сравнивать не буду. Разные сферы применения.

Где надо - используют. В большинстве случаев - не надо.

«Не всем нужна многопоточность», почти saahriktu!

Мне больше нравятся слова Алана Кея (который придумал Smalltalk и ООП) о том, как у него дети без проблем писали многопоток без багов и проблем на этом самом смоллтоке. Сишники тупее детей?

В процах вроде какие то инструкции есть - встретил ноль - конец празднику

Я смотрю на подрывы сишных жоп

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

чуть более чем во всех случаях локализация занимает существенно больше места. так что мимо.

Особенно учитывая что адресные регистры не редко были длиннее регистров данных и произвольно работать с адресами было геморройно. А тут нужен только инкремент. Такое обычно было доступно аппаратно для специальных индексных регистров.

разве вообще существуют процессоры, где нету специальных режимов «относительной» адресации [хотя бы в рамках страницы памяти, характерной для микроархитектуры]?

чуть более чем во всех случаях локализация занимает существенно больше места

Это распространённый миф от тех, кто плохо владеет языком. Хороший перевод занимает примерно столько же. Больше получается, когда переводят дословно («почесал свою голову своей рукой», ага). Есть, конечно, случаи, где однозначно всегда занимает больше, и если нет возможности увеличить длину строки, приходится как-то некрасиво сокращать. Но они достаточно редки.

Это распространённый миф от тех, кто плохо владеет языком. Хороший перевод занимает примерно столько же.

до тех пор пока мы все тут ждем примеры хорошего перевода, который смог влезть в графический интерфейс, ты заочно обоссан записан в категорию диванных-шизов уровня @vaddd

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

давай начнем с простого, такую банальщину как «open» или 'help' как локализуешь хорошо, чтобы заняло примерно столько же? предвувствую что кто-то опять обосрался. на чем-то чуть более сложном темболее ничего не выйдет.

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

Я лично (как один, так и в небольшой команде) переводил игры на NES, SMD, SNES. Иногда с раскрытием поинтеров (тогда места, не хватающего на одну строку, можно занять у другой, а то и вообще добавить), а иногда приходилось и жёстко прямо по живому в Hex-редакторе, не разбирая поинтеров. Проблемы со свободным местом проявляются не так уж часто. И нередко появление оных лишь указывает на то, что перевод плох: слишком дословен, много мусорных слов, не использованы деепричастные или причастные обороты там, где они нужны, а в английском другие формы построения предложений, и т.д.

Но да, это литературный перевод, а не перевод отдельных пунктов меню по одному слову каждый. Несомненно, в интерфейсах с главным меню, где есть Open и Edit, с этим сложнее, потому что не проявляются особенности целевого языка, позволяющие формировать предложения короче, чем в языке источнике. Обычно если язык более сложный в одном, он более простой в другом, то же касается и длины предложений. Но такой софт, с односложными пунктами меню, обычно всё же либо пишется с возможностью локализации, или исходники есть — там проблема локализации таким образом менее насущная. Да и на английском такие простые слова понятны практически всем, особенно учитывая, что они одинаковые везде.

Может с тем, что случаи, где впихнуть сложно, редки, я погорячился несколько (как-то даже не подумал про пункт с главным меню а ля виндовс), но уж точно не сильнее, чем ты со своим «чуть чаще, чем всегда».

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

Помню в пиратском переводе Daggerfall перевели Axe как Меч, потому что Топор слишкрм длинный.

Не поминай меня всуе, опущенный

не пробовал поискать информацию про среднюю длину слов в разных языках?

вот первое что выдал гугл

Average word length (in phonemes) was calculated for all 27,751 words in each language and was 7.48 ( SD = 2.51) for Dutch, 6.09 ( SD = 2.18) for English, 5.77 ( SD = 1.93) for French, 7.14 ( SD = 2.45) for German, and 7.84 ( SD = 2.28) for Spanish; F (4,138750) = 4284.86, p , 0.001

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

и это конечно же в среднем. что уж говорить про единичные случаи. то что кто-то превозмог и впихнулся в пару строчек на

NES, SMD, SNES

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

Но да, это литературный перевод, а не перевод отдельных пунктов меню по одному слову каждый. Несомненно, в интерфейсах с главным меню, где есть Open и Edit, с этим сложнее, потому что не проявляются особенности целевого языка, позволяющие формировать предложения короче, чем в языке источнике. Обычно если язык более сложный в одном, он более простой в другом, то же касается и длины предложений. Но такой софт, с односложными пунктами меню, обычно всё же либо пишется с возможностью локализации, или исходники есть — там проблема локализации таким образом менее насущная. Да и на английском такие простые слова понятны практически всем, особенно учитывая, что они одинаковые везде.

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

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

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

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

особенно сказки про совок доставляют!

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

переводил игры на NES, SMD, SNES.

шедевр, чиф-нет, или меджиктим?

не пробовал поискать информацию про среднюю длину слов в разных языках?

Ещё раз: сложность языка в одном компенсируется его же простотой в другом. Слова в русском длиннее, но самих слов требуется меньше, поэтому в итоге получается то же на то же или короче в достаточно длинных текстах (это не касается односложных пунктов меню).

Возьмите какую-нибудь современную хорошо переведённую с английского на русский книгу и сравните количество символов. Оно будет примерно таким же, как и в оригинале (главное сам переведённый текст сравнивать, конечно, а то бывают длинные сноски и прочее). Можно сделать то же и с играми или кино, просто с книгой проще, так как их можно относительно легко достать в plain text и сравнить прямо в лоб.

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

Предпочту не деанониться. Я не какой-то особо известный чел или что-то, но всё же на ЛОРе у меня одна «личность», в ретрогейминге другая, в музыке третья. Пусть так и остаётся, нечего их смешивать. Хоть я в плане переводов и ромхаккинга несколько отошёл от дел уже, давно в последний раз занимался.

Когда мне захотелось перевести одну клозед-сорс игрушку, я это делал hex-редактором в её бинарнике и всё влезло. Хотя если бы такого ограничения не было, возможно перевод и длиннее бы получился.

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