История изменений
Исправление KivApple, (текущая версия) :
Это ещё не всё. В том же Pascal поставили один байт для хранения длины - и что же получили? Кучу проблем и извращений, когда надо работать со строками длиннее 255 символов. Так что длину строки надо хранить как минимум в 16 битах, а лучше вообще в 32. Ведь строка может быть загруженным текстовым файлом, который нужно распарсить (зачем использовать для этого самописные функции, когда есть стандартные библиотечные строковые), а текстовые файлы длиннее 64КБ не такая уж редкость. Так что null-terminated строки это как раз таки пример удачного решения, когда не пришлось ничего менять даже когда компьютеры смогли обрабатывать строки из миллионов символов, которые раньше казались ненужными. И не придётся ничего менять даже когда мощности компьютеров позволят свободно обрабатывать многогигабайтные строковые данные. А вот на 64-битное дату-время пожмотились и получили проблемы.
Стандартизация вообще вещь такая, что надо учитывать всё. Нельзя говорить «никто не будет пользоваться нашей программой в 2038 году», «никому не нужны строки длиннее 256 байт», «в Интернете никогда не будет больше 4 миллиардов компьютеров». Надо сразу делать запас на несколько порядков (хороший пример - IPv6, которые не кончатся даже если мы начнём колонизировать другие звёздные системы и при этом будем применять единую адресацию). Ведь небольшое снижение производительности в будущем компенсируют (например, современные процессоры делают 64-битную арифметику с такой же скоростью, как и 32-битную), а вот за необходимость переписывать с нуля весь софт - проклянут.
Исправление KivApple, :
Это ещё не всё. В том же Pascal поставили один байт для хранения длины - и что же получили? Кучу проблем и извращений, когда надо работать со строками длиннее 255 символов. Так что длину строки надо хранить как минимум в 16 битах, а лучше вообще в 32. Ведь строка может быть загруженным текстовым файлом, который нужно распарсить (зачем использовать для этого самописные функции, когда есть стандартные библиотечные строковые), а текстовые файлы длиннее 64КБ не такая уж редкость. Так что null-terminated строки это как раз таки пример удачного решения, когда не пришлось ничего менять даже когда компьютеры смогли обрабатывать строки из миллионов символов, которые раньше казались ненужными. И не придётся ничего менять даже когда мощности компьютеров позволят свободно обрабатывать многогигабайтные строковые данные. А вот на 64-битное дату-время пожмотились и получили проблемы.
Стандартизация вообще вещь такая, что надо учитывать всё. Нельзя говорить «никто не будет пользоваться нашей программой в 2038 году», «никому не нужны строки длиннее 256 байт», «в Интернете никогда не будет больше 4 миллиардов компьютеров». Надо сразу делать запас на несколько порядков. Ведь небольшое снижение производительности в будущем компенсируют (например, современные процессоры делают 64-битную арифметику с такой же скоростью, как и 32-битную), а вот за необходимость переписывать с нуля весь софт - проклянут.
Исходная версия KivApple, :
Это ещё не всё. В том же Pascal поставили один байт для хранения длины - и что же получили? Кучу проблем и извращений, когда надо работать со строками длиннее 255 символов. Так что длину строки надо хранить как минимум в 16 битах, а лучше вообще в 32. Ведь строка может быть загруженным текстовым файлом, который нужно распарсить (зачем использовать для этого самописные функции, когда есть стандартные библиотечные строковые), а текстовые файлы длиннее 64КБ не такая уж редкость. Так что null-terminated строки это как раз таки пример удачного решения, когда не пришлось ничего менять даже когда компьютеры смогли обрабатывать строки из миллионов символов, которые раньше казались ненужными. А вот на 64-битное дату-время пожмотились и получили проблемы.