Ленивость, бережливость и переносимость регистров, учитывая сборочную интуицию любого языка, особенно C, который на один шаг выше сборки (таким образом, наследует много унаследованного кода сборки).
Вы согласитесь, что нулевой символ будет бесполезен в те дни ASCII, это (и, вероятно, так же хорошо, как контрольный символ EOF).
посмотрим в псевдокоде
function readString(string) // 1 parameter: 1 register or 1 stact entries
pointer=addressOf(string)
while(string[pointer]!=CONTROL_CHAR) do
read(string[pointer])
increment pointer
всего 1 регистр использования
дело 2
function readString(length,string) // 2 parameters: 2 register used or 2 stack entries
pointer=addressOf(string)
while(length>0) do
read(string[pointer])
increment pointer
decrement length
всего 2 регистра использовано
Это может показаться недальновидным в то время, но учитывая бережливость кода и регистра (которые были ПРЕМИУМ в то время, когда вы знаете, они использовали перфокарту). Таким образом, будучи «быстрее» (когда скорость процессора можно считать в кГц), этот «хак» был чертовски хорош и легко переносим для процессора без регистрации.
Ради аргумента я реализую 2 обычные строковые операции
stringLength(string)
pointer=addressOf(string)
while(string[pointer]!=CONTROL_CHAR) do
increment pointer
return pointer-addressOf(string)
сложность O (n), где в большинстве случаев строка PASCAL равна O (1), потому что длина строки предварительно привязана к структуре строки (это также означало бы, что эту операцию придется выполнять на более ранней стадии ).
concatString(string1,string2)
length1=stringLength(string1)
length2=stringLength(string2)
string3=allocate(string1+string2)
pointer1=addressOf(string1)
pointer3=addressOf(string3)
while(string1[pointer1]!=CONTROL_CHAR) do
string3[pointer3]=string1[pointer1]
increment pointer3
increment pointer1
pointer2=addressOf(string2)
while(string2[pointer2]!=CONTROL_CHAR) do
string3[pointer3]=string2[pointer2]
increment pointer3
increment pointer1
return string3
сложность O (n) и добавление длины строки не изменит сложности операции, хотя я допускаю, что это займет в 3 раза меньше времени.
С другой стороны, если вы используете строку PASCAL, вам придется перепроектировать свой API для учета длины регистра и порядка следования битов, строка PASCAL получила хорошо известное ограничение в 255 символов (0xFF), поскольку длина была сохранена в 1 байт (8 бит), и если вам нужна более длинная строка (16 бит -> что угодно), вам придется учитывать архитектуру на одном уровне вашего кода, что в большинстве случаев будет означать несовместимые строковые API, если вы хотите более длинную строку.
Пример: * * тысяча двадцать-пять
Один файл был записан с вашей предварительно добавленной строкой api на 8-битном компьютере, а затем должен был быть прочитан, скажем, на 32-битном компьютере, что ленивая программа посчитает, что ваши 4 байта - это длина строки, а затем выделите много памяти затем пытается прочитать это много байтов.
В другом случае считывание 32-байтовой строки PPC (с прямым порядком байтов) в x86 (с прямым порядком байтов), конечно, если вы не знаете, что одно записано другим, может вызвать проблемы.
1 байт (0x00000001) станет 16777216 (0x0100000), что составляет 16 МБ для чтения 1-байтовой строки.
Конечно, вы могли бы сказать, что люди должны договориться об одном стандарте, но даже 16-битный Unicode имеет маленький и большой порядок байтов.
Конечно, у С тоже будут свои проблемы, но затронутые здесь проблемы будут очень мало затронуты.